Absolutely, I never intended to commit unless I had buy-in from everyone.

I don't claim to understand the full impact of this, so your comments as
well as Roberts are always welcome.


By reverting the code (my local copy anyway) back to its original:
test.junit       <== SUCCESSFUL   Total time: 16 seconds
test.tomcat.32   <== NOT SUCCESSFUL   (Details below)
test.tomcat.33   <== SUCCESSFUL   Total time: 54 seconds
test.tomcat.40   <== SUCCESSFUL   Total time: 53 seconds
test.tomcat.41   <== SUCCESSFUL   Total time: 59 seconds


...
...
    [junit] Testcase: testInitDestroyInternal took 3.094 sec
    [junit]     Caused an ERROR
    [junit] null
    [junit] java.lang.NullPointerException
    [junit]     at
org.apache.struts.util.MessageResources.getMessageResources(MessageResources
.java:580)
    [junit]     at
org.apache.struts.action.ActionServlet.initInternal(ActionServlet.java:1145)
    [junit]     at
org.apache.struts.action.TestActionServlet.testInitDestroyInternal(TestActio
nServlet.java:112)
    [junit]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
...

The detail of the tomcat.32 failure lead back to the static call to:

 RequestUtils.applicationClass(String className)


So, what should I do with bug 14332 right now?



James Mitchell
Software Engineer/Struts Evangelist
http://www.open-tools.org

"Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former."
- Albert Einstein (1879-1955)


> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: Thursday, November 07, 2002 12:31 PM
> To: Struts Developers List
> Subject: Re: [Vote] Modify classloading in RequestUtils
>
>
> As a general principle, J2EE 1.4 (and later) requires app servers to make
> the webapp's class loader available via the getContextClassLoader() call.
> This feature is already supported by nearly every other server in the
> world.  Therefore, I'd really recommend that the TriFork folks upgrade
> their server to do the same.
>
> Please don't make this change until we've had more time to evaluate it's
> potential impacts.  I'm particularly concerned about the semantics of
> Class.forName() versus the current approach that uses the class loader
> that loaded RequestUtils itself.  That needs to be looked at more
> carefully, particularly with respect to multi-class-loader hierarchies
> like the one Tomcat 4 supports.
>
> Craig
>
>
> On Thu, 7 Nov 2002, James Mitchell wrote:
>
> > Date: Thu, 7 Nov 2002 11:13:35 -0500
> > From: James Mitchell <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: [Vote] Modify classloading in RequestUtils
> >
> >
> > Not sure if you caught the thread on the users list, or the bug recently
> > posted by Kjeld Froberg:
> >
> >  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14332
> >
> >
> > Here's the proposed code change:
> >
> > RequestUtils.java
> > -----------------------------------------------
> > From:
> >     public static Class applicationClass(String className)
> >         throws ClassNotFoundException {
> >
> >         // Look up the class loader to be used
> >         ClassLoader classLoader =
> >             Thread.currentThread().getContextClassLoader();
> >         if (classLoader == null) {
> >             classLoader = RequestUtils.class.getClassLoader();
> >         }
> >
> >         // Attempt to load the specified class
> >         return (classLoader.loadClass(className));
> >     }
> > -----------------------------------------------
> > To:
> >     public static Class applicationClass(String className)
> >         throws ClassNotFoundException {
> >             ClassLoader ctxLoader = null;
> >             try {
> >                     ctxLoader =
> Thread.currentThread().getContextClassLoader();
> >                     return Class.forName(className, true, ctxLoader);
> >
> >             } catch(ClassNotFoundException ex) {
> >                     if(ctxLoader == null) { throw ex; }
> >             } catch(SecurityException ex) {
> >
> >             }
> >             return Class.forName(className);
> >     }
> >
> > By changing these few lines, I am able to run the full test
> suite without
> > error. (And that includes the new test.tomcat.33)
> >
> > I'm not sure if this should be a [Vote] or a [commit and wait till they
> > complain], so I opted for the former.
> >
> > Even though I'm not truly sure of the consequences of this
> change, I'm +1.
> >
> >
> > James Mitchell
> > Software Engineer/Struts Evangelist
> > http://www.open-tools.org
> >
> > "Only two things are infinite, the universe and human
> stupidity, and I'm not
> > sure about the former."
> > - Albert Einstein (1879-1955)
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
<mailto:struts-dev-help@;jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

Reply via email to