You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Weston M. Price (Updated) (JIRA)" <ji...@apache.org> on 2012/01/07 12:01:39 UTC
[jira] [Updated] (QPID-3735) QpidActivation.start() should not use
the JCA WorkManager API control due to JNDI/Classloading issues
[ https://issues.apache.org/jira/browse/QPID-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Weston M. Price updated QPID-3735:
----------------------------------
Attachment: QPID-3735.patch
Fixes JNDI/Classloading issues on endpoint activation.
> QpidActivation.start() should not use the JCA WorkManager API control due to JNDI/Classloading issues
> -----------------------------------------------------------------------------------------------------
>
> Key: QPID-3735
> URL: https://issues.apache.org/jira/browse/QPID-3735
> Project: Qpid
> Issue Type: Bug
> Components: JCA
> Environment: All OS platforms, all supported JEE platforms other than JBoss EAP.
> Reporter: Weston M. Price
> Fix For: 0.15
>
> Attachments: QPID-3735.patch
>
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org