My last entry point resolver (EPR) related post talked about the property-entry-point-resolver which is a great way to specify the name of the method that should be invoked inside a service. There is another way to do this, of course.
(more…)

If you enjoyed this post, make sure you subscribe to my RSS feed!

Have you ever needed to aggregate multiple messages in an inbound router and were not sure exactly how to do this? Stephen Fenech, Consultant at Ricston Ltd, is our guest blogger for today and explains how to do this
(more…)

If you enjoyed this post, make sure you subscribe to my RSS feed!

When Mule invokes a method that returns a null, is this the same thing as invoking a void method? I didn’t think so and I wanted to write this blog post to document the difference in these two scenarios.
(more…)

If you enjoyed this post, make sure you subscribe to my RSS feed!

The standard entry-point resolver automatically determines which method in a class should be invoked. There are cases where a class may have two methods that take the same parameter list and rather than see the TooManySatisfiableMethodsException, it would be great if I could indicate which method to use. This is what the property-entry-point-resolver is there for.
(more…)

If you enjoyed this post, make sure you subscribe to my RSS feed!

Many of you who read my post called The Component Flow Stage wondered whether I will write about the next stage; the Outbound Flow Stage. Wonder no more, as here it is
(more…)

If you enjoyed this post, make sure you subscribe to my RSS feed!

My previous post on entry point resolvers (EPRs) focused on the Callable EPR but a more useful one if you have pre-existing code is the no-arguments entry point resolver. This will allow Mule to invoke a service method even if the method does not have any parameters.
(more…)

If you enjoyed this post, make sure you subscribe to my RSS feed!

In a completely asynchronous message flow in Mule, every message is handled by three distinct stages while it passes through a service. Each stage corresponds to a single thread and this is all controlled by the Staged Event Driven Architecture (SEDA) that Mule implements.
(more…)

If you enjoyed this post, make sure you subscribe to my RSS feed!

Interesting question from a class last week: Since splitting is an outbound routing pattern, what should I do if I wish to perform a splitting operation on an inbound route? What if I want to split while receiving messages?

One solution would be to create a new Inbound Router and implement the pattern there. This would certainly be the cleanest way of doing things. (If you do so, don’t forget to upload it to the MuleForge project so that others can use the router too!)
An easier solution would be to concatenate services together.

– Have a single service that receives the inbound message. If there is no router on the inbound and if this is a bridge service, the message is handed over to the outbound router collection.
– Use the appropriate outbound splitter router to split the message. Send all message fragments to a single endpoint, e.g., vm://split.message
– Set up this single endpoint (vm://split.message) as the sole inbound endpoint for a new secondary service.

The secondary service now has received the split message and can handle the individual message fragments individually.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Mule’s default mechanism to determine which method in a component should be used is encoded inside its Entry Point Resolver objects. The default one is sufficient in many situations but there are cases when this needs to be changed.
(more…)

If you enjoyed this post, make sure you subscribe to my RSS feed!