-
-
Notifications
You must be signed in to change notification settings - Fork 364
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())
.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, Autofac, and other containers are available in appropriately named NuGet packages.
If you don't need an IoC container for your application, you can use BuiltinHandlerActivator
and then retrieve the resulting IBus
instance from it after completing the configuration (or just use the IBus
returned from the final call to Start()
).
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.
Short answer: Configure a handler activator/container adapter and a transport, and then you're good to go.
It should be noted though, that subscriptions, timeouts, and sagas will then be stored in-mem, which is probably not suitable for production usage.
Check out the different bus modes for information on some more configurations.
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/Activation
namespace of Rebus.Tests
. It's very simple, however, because Rebus itself does not rely on auto-wiring or lifestyle.
Basic stuff
- Home
- Introduction
- Getting started
- Different bus modes
- How does rebus compare to other .net service buses?
- 3rd party extensions
- Rebus versions
Configuration
Scenarios
Areas
- Logging
- Routing
- Serialization
- Pub sub messaging
- Process managers
- Message context
- Data bus
- Correlation ids
- Container adapters
- Automatic retries and error handling
- Message dispatch
- Thread safety and instance policies
- Timeouts
- Timeout manager
- Transactions
- Delivery guarantees
- Idempotence
- Unit of work
- Workers and parallelism
- Wire level format of messages
- Handler pipeline
- Polymorphic message dispatch
- Persistence ignorance
- Saga parallelism
- Transport message forwarding
- Testing
- Outbox
- Startup/shutdown
Transports (not a full list)
Customization
- Extensibility
- Auto flowing user context extensibility example
- Back off strategy
- Message compression and encryption
- Fail fast on certain exception types
Pipelines
- Log message pipelines
- Incoming messages pipeline
- Incoming step context
- Outgoing messages pipeline
- Outgoing step context
Prominent application services