I am trying to unit test message handlers for NServiceBus 4.0.4. The bus is configured to use JSON serializer in the application using the Configure.Serialization.Json(); method call.
Whenever I call the Test.Initialize() method from the unit tests assembly I get the following exception: System.Configuration.ConfigurationErrorsException : Multiple serializers are not supported. Please make sure to only enable one
I tried calling Configure.Serialization.Json() and Serializers.SetDefault<JsonSerialization>() before calling the Test.Initialize() method without any success.
Does anyone know what am I doing wrong? All examples I see on the internet do not mention any Configure calls.
This issue has been reported previously here and looks like it will be fixed in the next NServiceBus build (both 4.0.5 and 4.1.0)
A workaround is to explicitly disable the xml serializer when enabling the json one.
Configure.Serialization.Json();
Feature.Disable<XmlSerialization>(); // hack to make NSB unit tests work
Related
I am wondering how I can test an application that's written with fasthttp using the httptest package in the base library of Go.
I found this guide which explains the testing pretty well, but the issue is that httptest does not satisfy the http.Handler interface so I have no idea how to do the http.HandlerFunc since fasthttp uses it's own fasthttp.ListenAndServe that's incompatible.
Any ideas on how to create a wrapper, or how to otherwise test a fasthttp written library end to end?
There are two possible approaches. Unit testing a handler isn't really viable as you would need to create a RequestCtx and stub/mock all necessary fields.
Instead, I would unit test the code that your fasthttp handlers call out
to. I would do e2e testing of the actual handlers themselves.
There is an in memory listener implementation that you could use to avoid actually listening on a TCP port or Unix socket. You would initialise the server but serve on this listener instead of on a network connection.
You would then create a HTTP client and call the relevant methods as normal but use this listener as the transport.
If you stub/fake anything that your handlers interact with then you could make this in-memory only with no external dependencies, i.e. like a unit test but it will actually doing a full system test.
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 can't seem to get the Castle Windsor Integration working for Mass Transit over RabbitMQ. Everything was working fine until I introduced Windsor into the picture. I referenced Castle.Windsor 3.2 and MassTransit.WindsorIntegration 2.9 and configured the container for use within my application. I'm registering the MassTransit Consumers via:
Container.Register(..., Types.FromThisAssembly().BasedOn<IConsumer>());
When I debug and inspect the container after this line is ran, I can see that it successfully registered all of the consumers along with all of my other components. I then have the following code to initialize and register the service bus:
var serviceBus = ServiceBusFactory.New(sbc =>
{
sbc.UseRabbitMq();
sbc.ReceiveFrom(Config.ServiceBusEndpoint);
sbc.Subscribe(sc => sc.LoadFrom(Container));
});
Container.Register(Component.For<IServiceBus>().Instance(serviceBus));
I am using the LoadFrom(IWindsorContainer container) extension method provided by MassTransit.WindsorIntegration.
All of the examples I've found so far stop here and indicate that this is all you should have to do. Unfortunately for me my Consumers are never being called and messages are just piling up in the queue (eventually timing out and going to error queue). The fact that messages are showing up in the Consumer queue at all (+ I see a single consumer bound to the queue via the RabbitMQ Admin Tool) indicates to me that the consumers are probably being subscribed properly - so I'm not sure where the problem lies.
I added NLog logging for Windsor and MassTransit but no errors are showing up in the logs. I'm not sure how I should proceed troubleshooting at this point. Any ideas?
Also, this application is currently just a console application using Topshelf for development. Ultimately it will be installed as a Windows Service. Not sure if that is relevant or not but I thought I'd mention it just in case.
UPDATE
As a test I created a very simple Consumer with a parameter-less constructor for processing a very simple test message. This Consumer is successfully called! The "real" Consumers however have dependencies that need to be injected into them via the constructor. I was hoping the Container would resolve these but apparently it's having some sort of trouble. Weird that nothing is showing up in the logs about it. Stay tuned...
Okay I figured it out. Somewhere along the way when I was adding/removing NuGet packages I somehow managed to delete a reference to a DLL (ServiceStack.Text.dll) that one of my components needed (RedisClientsManager).
I started the debugger, let all my components get registered then popped open the Immediate Window and attempted to resolve each component one by one (by calling container.Resolve<RegisteredType>()) until I found the one that threw the exception when I attempted to resolve it.
The Exception message from Windsor at that point told me exactly what the problem was. I'm a little lost as to why this wasn't being logged or why the Exception was not raised when the container itself attempted to resolve it. Anyhow, moral of the story is make sure your components resolve.
I have some code that is using the Restlet framework. It is writing an ERROR into my log4j log file:
2012-05-30 12:16:42,169 3278917 ERROR [STDERR] (Thread-97:) 30-May-2012 12:16:42 org.restlet.engine.http.connector.HttpClientHelper start
INFO: Starting the default HTTP client
Is there any way I can turn this logging off? I see there is a Client.getLogger(), but I can't see a way to use that to turn logging off.
You can rely on regular Java logging configuration (java.util.logging). Restlet Framework provides a simple way to adjust those properties, programmatically. Call for example:
org.restlet.engine.Engine.setLogLevel(Level.OFF);
Hi it maybe a little late but for me the following code did it:
ClientResource resource = new ClientResource();
resource.getLogger().setLevel(Level.WARNING); //<-- important
I left out the resource configuration and exectution because they are not important;-)
I have to following problem. In my application I used a service reference to a non-WCF service from some external company. I created a proxy class using svcutil.exe tool. Everything worked fine for about a year.
Yesterday however, clients reported that it's not possible to get any response from the service. I figured out that the error returned from the service was:
The formatter threw an exception while
trying to deserialize the message:
There was an error while trying to
deserialize parameter
http://serviceurl:someResponse. The
InnerException message was 'There was
an error deserializing the object of
type specificType
So, what I did I firstly updated the service reference and also generated the new proxy using svcutil.exe. The problem still occurs.
I resolve the problem by using either 1) wsdl.exe tool to generate proxy class 2) add web reference (which behind the scenes using wsdl.exe tool internally to create proxy).
My question is : Why everything worked fine for a quite long time even if I used a service reference? How can I checked whether has something changed in the web service? Any help would be appreciated.
Contact the company that provides the web service and find out what changed.