Details
-
Bug
-
Status: Closed
-
Blocker
-
Resolution: Fixed
-
2.3AS
-
None
Description
JNDI and JMX both use "system-wide" "registries" of objects. These objects, for uima-as, can be loaded from a Resource Manager in cases where the uima-as classes are on the Resource Manager's classpath. A use case where this can occur is a UIMA aggregate containg 2 PEAR descriptors, each having a potentially different version of uima-as in the PEAR's classpath, being used as a client to a remote uima-as service. (Note that the uima-as client for this is represented in UIMA as a "custom resource specifier", so this use case can also apply to future "custom resources".)
The system-wide registries for JNDI and JMX use a string handle to locate objects, and cache found objects in the registry. The first use loads the object, using the class loader in effect at the place where the lookup is requested. For uima-as being used as a custom resource, the class loader used is the UIMA class loader associated with the current resource manager.
If, subsequently, another resource manager instance (actually, another class loader instance within the UIMA resource manager) is used to run the uima-as classes, the lookups by name for objects in these registries will succeed, but will return objects that were loaded under a different class loader. This causes ClassCastExceptions, because the superclasses / interfaces used in the currently running code (running under the 2nd classloader) no longer are the superclasses / interfaces of the objects retrieved under the 1st classloader.
See http://markmail.org/message/2r5coddmuuprucyk for discussion of this issue in the context of running the Configuration Descriptor Editor (CDE).