There is also the possibility to use the Digester's caller ClassLoader. The
little helper class I attach with this email is quite helpful in getting the
caller's ClassLoader. With this approach, I would think there is no need to
specify additional options for a class loader, assuming of course the caller
of the Digester is able to instantiate all the needed classes.
I'd be interested anyway about any comments on this approach (using the
attached class). It has worked for me in many environment (Tomcat, WebLogic,
standalone apps, ...) without problems. But I never looked into the security
aspects and the overall validity of the approach. All I can say is that the
JDK uses similar methods for loading resources: it looks at the execution
stack in order to get a reference to the caller's ClassLoader. The only
difference is that the JDK does this using native call, and the attached
class derives from the SecurityManager in order to do this without native
code.
Fr.
-----Original Message-----
From: Scott Sanders [mailto:[EMAIL PROTECTED]]
Sent: 17 July 2001 22:00
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Difficulties with Commons-Digester 1.0
I am aware of this issue, and in talking with Craig, the solution is to add
a boolean useContextClassLoader to digester to turn this on and off. I will
be updating the Commons Digester to handle this hopefully in the next week
or two. If you want to send a patch, feel free ;-)
Scott Sanders
----- Original Message -----
From: "Immanuel, Gidado-Yisa" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 11:21 AM
Subject: Difficulties with Commons-Digester 1.0
> I'm cross posting this on Struts-dev and Commmons.
>
> I attempted to incorporate the commons-digester_1.0 into my struts-
> based application. A quick note on how I'm using it: In one of
> my actions, I 'digest' an xml file. The digester.jar,
> collections.jar, and beanutils.jar are all placed in 'WEB-INF/lib'
> for the web-app in question.
>
> The difficulty that I ran into is that the Digester could not find
> the classes that needed to be instantiated. I found a solution by
> comparing the struts and commons versions of ObjectCreateRule. The
> struts-ObjectCreateRule locates a class using the current-class'
> ClassLoader, while the commons-ObjectCreateRule first tries to use
> the context-ClassLoader that is set in the currentThread.
>
> struts.digester.ObjectCreateRule (line 151):
> // Instantiate the new object and push it on the context stack
> Class clazz = Class.forName(realClassName);
>
> commons.digester.ObjectCreateRule (line 156):
>
> // Check to see if the context class loader is set,
> // and if so, use it, as it may be set in server-side
> // environments and Class.forName() may cause issues
> ClassLoader ctxLoader =
> Thread.currentThread().getContextClassLoader();
> if (ctxLoader == null) {
> clazz = Class.forName(realClassName);
> } else {
> clazz = ctxLoader.loadClass(realClassName);
> }
>
> In the commons.digester.ObjectCreateRule, I made the following
> changes, to enforce using the class' ClassLoader:
>
> ClassLoader ctxLoader =
> Thread.currentThread().getContextClassLoader();
> - if (ctxLoader == null) {
> + if (true) {
> + System.out.println("OBJECTCREATERULE IS USING
Class.forName()...");
> clazz = Class.forName(realClassName);
> } else {
> clazz = ctxLoader.loadClass(realClassName);
> }
>
> And this worked for me. I understand (more or less) the intent behind
> the code in commons-ObjectCreateRule, but I'm not enough of an expert
> in ClassLoaders to suggest a good solution. Craig, can you help out
> on this one? Perhaps, there's something I need to do that does not
> involve changing the commons-digester1.0 at all?
>
> Thanks,
> Gidado
>
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***********************************************************************
ClassContextHelper.java
