Details
Major Description
There is an issue with the QpidActivation.start() method using the JCA WorkManager/Work API to asynchronously activate the endpoint (MDB basically). When the WorkManager creates a new thread the context classloader does not contain the class files from the RAR. As a result, when we attempt to lookup the Destination from JNDI to begin delivery of messages to the endpoint, a javax.naming.Reference is returned versus the actual object the Reference represents. Further, the ObjectFactory that has been set to create the Reference cannot be located by the WorkManager class loader and as a result, we get a ClassCastException if we don't manually re-create the Destination objects.
I have noted this behavior in both Geronimo, Glassfish and Weblogic. Note, it works in JBoss EAP largely 'by accident' due to differences in the EAP classloading architecture (flat versus hierarchal).
The solution is to start our own thread in the QpidActivation.start() method as opposed to using the WorkManager API. Our use of the WorkManager/Work API is very limited in that we don't rely on the Work ExcecutionContext or any callback methods, we are simply using it so as to be able to deploy multiple endpoints in parallel without blocking. Starting our own thread achieves the same result without the extra work involved when we use the WorkManager API.
This solution would go a long way to simplifying the examples across multiple application servers in handling JNDI access with inbound connectivity.