Java and UIMA things holding on to objects loaded via Resource Manager fail 
when switching to another Resource Manager class loader instance
--------------------------------------------------------------------------------------------------------------------------------------------

                 Key: UIMA-1713
                 URL: https://issues.apache.org/jira/browse/UIMA-1713
             Project: UIMA
          Issue Type: Bug
          Components: Async Scaleout
    Affects Versions: 2.3AS
            Reporter: Marshall Schor
            Assignee: Jerry Cwiklik
            Priority: Blocker


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).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to