-
Notifications
You must be signed in to change notification settings - Fork 0
Configuration api
The configuration API is a fluent configurer, that revolves around a bunch of configurers and the assumption that you're backing your application with an IoC container. It basically goes like this:
Configure.With(myContainerAdapter)
.SomeAspect(s => s.ChooseSomeSetting())
.CreateBus().Start();
where myContainerAdapter
is an instance of something that implements IContainerAdapter
, the purpose of which is to adapt the registration API and a few behavioural aspects of IoC containers to match those required by Rebus. Adapters for Castle Windsor, StructureMap, and Autofac are available in the Rebus.Castle.Windsor
, Rebus.StructureMap
, and Rebus.Autofac
packages.
If you don't need an IoC container for your application, you can use BuiltinContainerAdapter
and then retrieve the resulting IBus
instance from it after completing the configuration.
If you're interested, please check out the page about container adapters.
In the example above, SomeAspect
and ChooseSomeSetting()
are just shown in order to exemplify the general pattern where a method is called to choose which aspected should be configured, and in the Action<TConfigurer>
you can then call stuff in order to configure some aspect of Rebus.
There's one special case to this: The first call to Configure.With(...)
will return a special configurer, that allows for logging to be configured. This is only possible on the first call, because logging should be properly set up before all the other configurers are run, thus allowing configurers to log things properly if they want.
Moreover, several configurers can only be called once because otherwise it would lead to an ambiguous configuration. E.g. configuring serialization twice will yield a ConfigurationException
. You can, however, configure Decorators
and Events
mutliple times if you like.
This question can't be answered in one single sentence, because it depends on what you're planning on using Rebus for. Often, when dealing with libraries and frameworks that can be configured, you're better off staying away from configuring stuff explicitly if it is the default anyway, so here's the minimum configuration needed to get up and running with the bus in different modes...
Check out the different bus modes for information on which configurations make sense.
If you're interested in implementing your own adapter, please take a look at one of the existing adapter implementations. Your adapter implementation should be able to pass a suite of tests currently residing in the Contracts
namespace of Rebus.Tests
. It's very simple, however, because Rebus itself does not rely on auto-wiring or lifestyle.