Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Date: Mon, 29 Oct 2012 17:56:12 +0000 (UTC)
From: "Jody Grassel (JIRA)" <jira@apache.org>
To: dev@openjpa.apache.org
Message-ID: <1437878068.39942.1351533372950.JavaMail.jiratomcat@arcas>
In-Reply-To: <1436229834.39136.1351522572285.JavaMail.jiratomcat@arcas>
Subject: [jira] [Work started] (OPENJPA-2288) MetaDataRepository should be
 able to filter classes from other app ClassLoaders in JEE Env
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/OPENJPA-2288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on OPENJPA-2288 started by Jody Grassel.

> MetaDataRepository should be able to filter classes from other app ClassLoaders in JEE Env
> ------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-2288
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2288
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: kernel
>    Affects Versions: 2.1.1, 2.2.0
>            Reporter: Jody Grassel
>            Assignee: Jody Grassel
>         Attachments: OPENJPA-2288-2.1.x.patch
>
>
> When an enhanced Class is loaded by a ClassLoader, its static initializer registers it with metadata in a map in the PCRegistry.  Every MetaDataRepository that registers as a listener with the PCRegistry will receive each class, regardless of whichever ClassLoader it is associated with.  In a JEE environment, this means all Classes from all Applications (including stopped Applications whose ClassLoaders have not yet been Garbage Collected) are received by each MDR instance in the MDR.processRegisteredClasses() method.
> It has been found that there is a problem in the MDR.processRegisteredClasses() method.  While processing each registrant, one of the first things it attempts to do is instantiate the class to determine whether the version level of the enhancer that enhanced the class is compatible with the runtime.  If the class constructor contains application logic that addresses static (session-context sensitive) data and does not gracefully capture the resulting RuntimeException, it can cause the JPA operation responsible for triggering the MDR.pRC() operation to fail.
> As a Compatibility option, I propose enabling a filter that eliminates classes that are not loadable through the envLoader (or Thread Context ClassLoader when envLoader is null).  This will eliminate instantiating Classes from other applications (thus eliminating the execution of potential application custom logic embedded in the constructors) inappropriately.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira