[
https://issues.apache.org/jira/browse/JXPATH-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Trimble updated JXPATH-127:
--------------------------------
Attachment: classloading_fix_jxpath14.patch
Patch for the trunk of JXPath:
http://svn.apache.org/repos/asf/commons/proper/jxpath/trunk
Changes class loading strategy in JXPath to consult context class loader.
> 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.
