Entry Point Resolver Sets
One interesting feature that I have rarely used in Mule 2 is the ability to have multiple entry point resolvers (EPRs) configured in a single model. This was unavailable in Mule 1 and is a rather neat way of combining multiple EPRs inside a single model rather than split your configuration into multiple models.
Consider the following Java class:
public class EPRSetService { public String aMethod(Integer aNumber) throws Exception { return "The Ultimate Answer!"; } public String helloMethod (String aString) { if (aString == "Hello") { return "Hello there!"; } else { return "Hello?"; } } public String goodbyeMethod (String aString) { if (aString == "Hello") { return "Pardon?"; } else { return "Good-Bye!"; } } }
As you can see here, we have three methods. If Mule receives a message containing an integer, it can use reflection to find the right method. If a message containing a string is received, Mule will throw an exception since it cannot figure out which method to use.
I created a Mule configuration that has a model with the following EPRs:
1 The reflection entry point resolver. This works in pretty much the same way as the legacy EPR does by matching the parameters to methods with the MuleMessage payload.
2 The method entry point resolver. I wrote about this EPR in a previous blog post.
The configuration is as follows:
<model name="setOfEPR"> <entry-point-resolver-set> <reflection-entry-point-resolver/> <method-entry-point-resolver> <include-entry-point method="helloMethod"/> </method-entry-point-resolver> </entry-point-resolver-set> <service name="SetOfEPRService"> <inbound> <inbound-endpoint ref="forSetEPR"/> </inbound> <component class="com.ricston.tests.EPRSetService"/> </service> </model>
Note the entry-point-resolver-set XML that contains two EPRs. They are used in sequence so the second EPR is invoked only if the first one does not find a match.
I ran tests against this to verify the behaviour:
public void testSetOfEPR () { MuleMessage aReply = null, anotherReply = null; try { MuleClient myClient = new MuleClient (); aReply = myClient.send ("forSetEPR", new DefaultMuleMessage (42),1000); anotherReply = myClient.send ("forSetEPR", new DefaultMuleMessage ("Hello"),1000); } catch (MuleException e) { fail (e.getDetailedMessage()); } assertNotNull (aReply); assertNotNull (aReply.getPayload()); assertTrue (aReply.getPayload() instanceof String); assertEquals ((String) aReply.getPayload(), "The Ultimate Answer!"); assertNotNull (anotherReply); assertNotNull (anotherReply.getPayload()); assertTrue (anotherReply.getPayload() instanceof String); assertEquals ((String) anotherReply.getPayload(), "Hello there!"); }
Everything worked like clock-work 
In this case, when I sent an integer to Mule, the right method was picked up as expected. When a string was sent to Mule, the first EPR failed to identify a suitable method to use and so the second one kicked in.
Essentially, this means that having a set of EPRs can help hide certain exceptions (in this case the TooManySatisfiableMethods exception) as there is an automatic solution for it.
If you enjoyed this post, make sure you subscribe to my RSS feed!
November 16th, 2009 at 10:05 AM
[...] Entry Point Res … 11/12 [...]