Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1563503691.1233266039638.JavaMail.jira@brutus>
Date: Thu, 29 Jan 2009 13:53:59 -0800 (PST)
From: "Matt Benson (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (JXPATH-127) Change dynamic class loading to
 consult context class loader.
In-Reply-To: <454945541.1230073844262.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JXPATH-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668623#action_12668623 ] 

Matt Benson commented on JXPATH-127:
------------------------------------

I am as yet undecided on this approach though the fact that [lang]'s ClassUtils#getClass(...) family of methods default to the current Thread context loader in a similar manner.  That said, the code you've borrowed from the article in question is marked as copyrighted (I like the way you've granted the ASF permission to use someone else's code, btw) so there would have to be a formal IP grant before [jxpath] could use this patch as-is.  It would be simpler to copy [lang]'s code and use that within [jxpath]. 

> Change dynamic class loading to consult context class loader.
> -------------------------------------------------------------
>
>                 Key: JXPATH-127
>                 URL: https://issues.apache.org/jira/browse/JXPATH-127
>             Project: Commons JXPath
>          Issue Type: Improvement
>            Reporter: John Trimble
>             Fix For: post-1.3
>
>         Attachments: classloading_fix_jxpath14.patch
>
>
> For dynamically loading classes, JXPath currently uses Class.forName(...). This means all classes loaded by JXPath must be visible to whatever class loader loaded JXPath. This is restrictive in large frameworks and web applications where multiple class loaders are in use. In particular, in an EJB3 application deployed on Weblogic, the shared jars between different EJB modules are loaded with a separate class loader than the modules themselves. Consequently, if the jxpath.jar is among the general libraries for the application, then a specific EJB module will be unable to reference static methods of classes within its own module in an xpath expression. For example, consider the following lines of code in an EJB module class:
> JXPathContext context = JXPathContext.newContext(new Object());
> Object value = context.getValue("SomeClass.getSomething()");
> This will fail, with a ClassNotFoundException, if SomeClass is a class in the module, but jxpath is a general library for the application.
> Attached (or will be once I figure out how) is a patch for JXPath that gets around this issue. The patch changes the class loading strategy to use the context class loader, when it appears appropriate, to dynamically load classes. The strategy is based on suggestions and example code from:
> http://www.javaworld.com/javaworld/javaqa/2003-06/01-qa-0606-load.html 
> Assuming all class loaders involved delegate to their parent class loader (as recommended in the API), currently working code, that uses JXPath, should only be affected by this change if the current class loader (the class loader that loaded JXPath) is not in an ancestor/descendant relationship with the context class loader.

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