You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Marshall Schor (JIRA)" <ui...@incubator.apache.org> on 2010/01/05 16:22:54 UTC
[jira] Created: (UIMA-1713) Java and UIMA things holding on to
objects loaded via Resource Manager fail when switching to another Resource
Manager class loader instance
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.
[jira] Closed: (UIMA-1713) Java and UIMA things holding on to
objects loaded via Resource Manager fail when switching to another Resource
Manager class loader instance
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik closed UIMA-1713.
-------------------------------
Resolution: Fixed
Fix Version/s: 2.3AS
Modified UIMA AS client code to create ActiveMQConnectionFactory on demand using class constructor instead of using JNDI. The ConnectionFactory is no longer a singleton object cached in the JNDI repository. A ConnectionFactory is created during initialization of the UIMA AS client and while recovering from a lost connection. This fixes Class Loader problem described in this JIRA.
Unable to reproduce a problem with JMX registry although it *is* a shared Resource in a JVM.
> 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
> Fix For: 2.3AS
>
>
> 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.