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