Warning: A non-numeric value encountered in /home/ricston2/public_html/blogarchive/wp-content/themes/Divi/functions.php on line 5766

Last week, I blogged about an unusual error I encountered while coding and mentioned that I was not sure why this happened. I’ve since solved the problem and present the explanation to you here.

In last week’s post, I explained how I wanted to use Component Bindings but received a NoSatisfiableMethodsException when I declared the binding interface in my config but did not properly declare the interface for use in my component.

Clearly, my code was incomplete as the only way I can bind my component to the interface (as explained on MuleSoft’s wiki) is if I declare a field in my code. My mistake was to have a field without getter and setter methods.

However, the absence of getter and setter methods did not trigger any alerts when Mule loaded. Since the MuleSoft wiki explicitly states: ‘which is initialized during the bootstrap stage by the Mule configuration builder’, I can only assume that this bootstrap process was okay with this.

Once I passed a message through Mule, I got the exception mentioned. Anyone who has worked with the entry-point resolution mechanism recognises that exception as Mule’s way of telling you that it could not find a suitable method to invoke. As mentioned last week, changing the entry-point resolver did not improve the situation so whatever was wrong was affecting the entry-point resolvers too.

Allow me to reproduce the error here:

Exception stack is:
1. Could not find entry point on: "com.ricston.tests.
ProductUpdateServiceComponent" with arguments:
"{interface com.ricston.tests.KeyMappingInterface}"
 (org.mule.model.resolvers.NoSatisfiableMethodsException)
  org.mule.component.DefaultLifecycleAdapter:274
(http://www.mulesource.org/docs/site/current2/apidocs/
org/mule/model/resolvers/NoSatisfiableMethodsException.html)
**********************************************

Note that the entry point which cannot be found is an entry point ‘with arguments {interface com.ricston.tests.KeyMappingInterface}‘. The entry-point resolvers are obviously trying to look for a method which accepts a KeyMappingInterface. This is unusual and I could not find a reference to it in the documentation.

To test this theory, I created the following object:

public class Sample implements KeyMappingInterface {

	public void addKeyMapping(String aProduct) {
	}

}

I don’t need any code here so I left the method blank. I left the configuration as-is:


	
		
	
	
		
			
		
	

Here, the component is still configured within the service with the element. Looking at this config, you’d think that I was going to use component bindings. Let’s take a look at the changes I made to the component now:

public boolean process (KeyMappingInterface aKeyMap) {
	if (aKeyMap != null) {
		return true;
	}
	return false;
}

public String processProduct(String aProduct) {
	// All my other code is here
}

The method I originally expected to invoke is the processProduct () method but I now added another one. The process() method accepts a single parameter which is a KeyMappingInterface.

Since we now have a method in this class that accepts a KeyMappingInterface, the entry-point resolvers cannot claim that this is not the case. If, as I suspected, the entry-point resolvers use the element as another way to pre-select the entry-point at design time, then I should receive a boolean result. I setup a test case for this:

public void testCompleteFlow()
{
	MuleMessage reply = null;
	MuleClient client;
	Sample aTest = new Sample ();
	try {
		client = new MuleClient();
		reply = client.send("FromMagento", aTest, null);
	} catch (MuleException e) {
		fail (e.getDetailedMessage());
	}

	assertNotNull(reply);
        assertNotNull(reply.getPayload());
        assertTrue ((Boolean)reply.getPayload());
}

As you can imagine, the whole thing worked like a charm.

Conclusion:
Another way to specify which method Mule should invoke from your custom classes is to use the child elements in your config to refer to an interface that the message payload implements (and which is accepted by one method in your class).
Note that this is not documented behaviour so it may not work as described here in future versions of Mule. If anyone from MuleSoft thinks that this is a bug of sorts, please let me know and I’ll fill in a JIRA for you.