More Entry Point Resolver Fun
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.
Wanting to see this in action, I adapted the configuration and code for my previous experiments with the no-arguments-entry-point-resolver. I created the following model in a configuration file:
<model name="propertyEPR"> <property-entry-point-resolver property="methodName"/> <service name="propertyService"> <inbound> <inbound-endpoint ref="forPropertyEPR"/> </inbound> <component class="com.ricston.tests.NoArgService"/> </service> </model>
(Note that the code for the NoArgService is available on the previous post about entry point resolvers) The entry point resolver (EPR) is configured with a reference to a property name. The EPR will look at the MuleMessage and look for a property with this name. If there is one, it will use the property’s value and search for a method with this name. Using the following test code:
public void testPropertyEPR () { MuleMessage aReply = null; Map props = new HashMap (); props.put("methodName", "queryName"); try { MuleClient myClient = new MuleClient (); aReply = myClient.send ("forPropertyEPR", new DefaultMuleMessage ("Hello",props),10000); } catch (MuleException e) { fail (e.getDetailedMessage()); } assertNotNull (aReply); assertNotNull (aReply.getPayload()); assertTrue (aReply.getPayload() instanceof String); assertEquals ((String) aReply.getPayload(), "Antoine Borg"); }
I thought that this would work but it fails on the third assertion. This was puzzling since I was setting up the property name on the MuleMessage in my test case and I did have the EPR configured properly in the configuration too. The assertion failed explaining that the payload type was not a String. Looking at the log file, I saw that the EPR did not find any suitable method to invoke.
Since I know that the method exists, this EPR must not like no-arg methods too much. I decided to test this theory by creating a new class with methods that accept String parameters:
public class StringService { public String queryName (String request) { if (request == "Hello") { return "Antoine Borg"; } else { return "Hello?"; } } public String queryNumber (String request) { if (request =="Number?") { return "+32 123 456 789"; } else { return "Hello?"; } } }
I modified the configuration to refer to this class and the whole thing worked!
Conclusion: If you have a class that has several methods which have the same argument list, the property-entry-point-resolver lets you choose a method to invoke at run-time by adding this property name to the MuleMessage.
If you enjoyed this post, make sure you subscribe to my RSS feed!
Tags: entry point resolver, no-args-entry-point-resolver, property-entry-point-resolver
October 29th, 2009 at 9:03 AM
[...] More Entry Poin … 10/19 [...]