[
https://issues.apache.org/jira/browse/WINK-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773650#action_12773650
]
Hudson commented on WINK-226:
-----------------------------
Integrated in Wink-Trunk-JDK1.5 #237 (See
[http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5/237/])
: need fallback for Class.forName in J2EE environments
> need fallback for Class.forName in J2EE environments
> ----------------------------------------------------
>
> Key: WINK-226
> URL: https://issues.apache.org/jira/browse/WINK-226
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-226.patch
>
>
> In J2EE environments, the Wink libraries may be managed by a different
> classloader (A) than the Application subclass (B). In these cases, (A) needs
> to load (B) by way of Class.forName(B). However, due to the J2EE
> environment, and classloader hierarchies, (A) does not have visibility into
> (B).
> The solution is to use the thread context classloader instead of
> Class.forName, which uses the system classloader. This "try thread context
> classloader first, then fallback to system classloader" functionality is
> built into org.apache.commons.lang.ClassUtils.getClass(String). We already
> have a dependency on Apache commons in wink-server, so I figure we can just
> use that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
