It seems that in version 5 of NServiceBus the API allows you to inject an instance of your own IoC container into NServiceBus with the following syntax:
configuration.UseContainer<UnityBuilder>(c => c.UseExistingContainer(unityContainer));
The only mentioned syntax for version 4 is as follows:
Configure.With().UsingContainer<UnityObjectBuilder>();
Is it correct that you cannot inject an instance of your own container in version 4 of NServiceBus? I.e. you can only tell NServiceBus to use another container, but not yours specifically.
Yes, that's supported. The syntax is:
Configure.With().UnityBuilder(container);
Related
I'm trying to get rid of XML in my project.
I already tried to add this:
JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
sf.setResourceClasses(CustomerService.class);
sf.setAddress("http://localhost:9000/");
sf.create();
to my Activator class, but my bundle wont start with this.
So, how usually people configuring endpoints?
(Sorry, no code, just some high level insights from my experience/projects)
I use jersey and its integration into the OSGi environment. I.e. org.glassfish.jersey.servlet.ServletContainer to which I register all jax-rs resources. This way, I can use whatever HTTP server implementation is available (for example, jetty) and configure it via the OSGi system environment properties.
For simplicity, I re-register annotated OSGi (declarative) services as singleton resources/endpoints into that ServletContainer.
Maybe, CXF has also a similar approach.
How to deal with error handling in spring-kafka version 1.1.x?
As I see it was introduced in version 2.0...
In 1.x you can add an ErrorHandler implementation to the listener container (or container factory if you are using #KafkaListener annotations).
The 2.0 feature was added to make it easier to configure if you want a different error handler for each listener when using annotations.
I'm trying to configure rebus using app.config. This lines are working in older versions of rebus, but in the new version (Rebus 2) it does not work.
.Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig())
.MessageOwnership(o => o.FromRebusConfigurationSection())
What are the equivalent ones in rebus 2?
Unfortunately, there's no equivalent for the queue name and worker configuration in Rebus 2.
You can configure your endpoint mappings with the Rebus.XmlConfig package by going
Configure.With(...)
(...)
.Routing(t => t.AddEndpointMappingsFromAppConfig())
(...)
though.
Maybe there will be some way of picking up settings from app.config/web.config in the future - but the configuration thing is one big thing that I know will not be portable to .NET core if it's based on ConfigurationManager.AppSettings, so I intentionally left it out.
In the NServiceBus interface, why are some things configured like this:
NServiceBus.Configure.Instance.Configurer.ConfigureComponent(ComponentCallModelEnum.Singleton);
And some things are configured like this:
NServiceBus.Configure.With().DoNotAutoSubscribe();
What is the significance of "Instance" here?
In the first case you are configuring a specific component into the NSB container. For instance you may want to load an NH ISessionFactory into the NSB container as a singleton object. In the second case you are configuring NSB behaviour. The "Instance" is simply a way to statically access the Configure class. Using "With" forces certain configuration behaviour including the order in which things are configured.
I'm attempting to use Windsor and NHibernate in a medium trust environment and I'm running up against some problems with permissions. I have read through the other questions on this but I'm using Windsor's NHibernate facility which I haven't seen discussed.
For some reason there is a dependency on the Castle.Service.Transations assembly when the container starts up. This then tries to create and instance of:
Castle.Services.Transaction.CallContextActivityManager()
A security exception is raised as CallContextActivityManager tires to use SetData in System.Runtime.Remoting.Messaging.CallContext which is only allowed if you have infrastructure permission. I'm guessing that medium trust apps don't.
Does anyone know a way around this security issue in medium trust? Should I dump the NHibernate facility and register it manually with the container?
You can get around this by registering the TLSActivityManager in the container (for type IActivityManager). The DefaultTransactionManager (used by NHibernateIntegrationFacility) will then use this ActivityManager instead of firing off a new CallContextActivityManager.