Re: AW: Patch for Context Class Loader problems (was Re: Fresh CV S checkout - AdminClient list fails)

[Ravi Kumar <rk...@borland.com>]

Glen,

I think I had brought this up earlier ...

Isn't what you are proposing (for JRun) incorrect behaviour as per the Servlet
spec?
Isn't a context expected to be self contained and isolated from whatever is in
the container's classpath?

Rgds
Ravi

Glen Daniels wrote:

> OK, got a problem for you. :)
>
> JRun is integrating Web Services into our next version of the app server,
> and we have a tech preview going out on our current version demonstrating
> this stuff.  It uses Axis, and puts the axis.jar into a system-level lib/
> directory so it's automatically accessible via all webapps. (do you see
> where I'm going yet?)  Thus the AxisServlet class is actually loaded by a
> JRun-wide class loader, *not* the webapp-specific classloader which has
> access to the WEB-INF/classes directories, etc.
>
> So this patch don't work for us.  We do however set the context classloader
> correctly - so I think we're gonna have to change the patch to only set it
> if it's not set.  Now if there is a performance hit associated with the
> check, I'd suggest we check it once and store the result in a flag that
> indicates we don't need to check it again.
>
> --Glen
>
> > -----Original Message-----
> > From: Davanum Srinivas [mailto:dims@yahoo.com]
> > Sent: Thursday, October 04, 2001 12:23 PM
> > To: axis-dev@xml.apache.org
> > Subject: Re: AW: Patch for Context Class Loader problems (was
> > Re: Fresh
> > CVS ch eckout - AdminClient list fails)
> >
> >
> > Glen, Dr. Jung,
> >
> > I looked into the patches. I don't think my patch will
> > interfere with Dr Jung's code at all. I
> > again re-state the problem. Under some of the old Servlet
> > Engines like Tomcat 3.2.3 if you print
> > the Thread.currentThread().getContextClassLoader() in
> > AxisServlet's init function. It will print
> > "sun.misc.Launcher$AppClassLoader@71732b" which is the system
> > default class (see
> > http://www.jguru.com/faq/view.jsp?EID=4318). This is because
> > the Servlet Engine does not set the
> > Context Class Loader at all. This is exactly what my patch does.
> >
> > Now if the patch that i sent leads to problems, i promise to
> > send in patches to fix them or will
> > ask you guys to comment the line out........This should not
> > be that difficult.
> >
> > Thanks,
> > dims
> >
> > --- "Jung , Dr. Christoph" <ch...@infor.de> wrote:
> > > -----Ursprüngliche Nachricht-----
> > > >Von: Davanum Srinivas [mailto:dims@yahoo.com]
> > > >Gesendet: Donnerstag, 4. Oktober 2001 17:25
> > > >An: Tom Jordahl
> > > >Cc: axis-dev@xml.apache.org
> > > >Betreff: RE: Patch for Context Class Loader problems (was
> > Re: Fresh CVS
> > > >ch eckout - AdminClient list fails)
> > >
> > > >No Tom. Dr. J's comment was that there should be a better
> > class-loading
> > > mechanism for all the
> > > >things that need to be picked up at runtime that are not
> > available to the
> > > class loader that loaded
> > > >the Axis Servlet. I absolutely agree with this. But that
> > does not mean that
> > > my fix will stop us
> > > >from implenting such a mechanism.
> > >
> > > I absolutely agree, my comment was just to extend a bit on
> > the important
> > > classloader issue. I
> > > didn´t want to confuse, sorry.
> > >
> > > >Talking theoretical is great!!! We have a real-world
> > project that has to be
> > > implemented on some
> > > >Servlet Engines in a production environment for which we need a FIX
> > > NOW!!!!. After all you can
> > > >comment out the single line of code ANYTIME!!!!
> > >
> > > Attached is my work-around to that problem. The diff refactors
> > > org.apache.axis.transports.http.AxisServlet
> > > such that subclasses
> > (org.jboss.net.axis.AxisServiceServlet) can produce
> > > different MessageContexts (here
> > > org.jboss.net.axis.ClassLoaderAwareMessageContext).
> > >
> > > The org.jboss.net.axis.ClassLoaderAwareMessageContext in
> > conjunction with
> > > the org.jboss.net.axis.ClassLoaderAwareAxisServer is able
> > to reestablish the
> > > right
> > > service classloader while doing a setTargetService(String
> > serviceName).
> > >
> > > Maybe that also solves the problem of Mr. Srinivas? As said
> > before, having
> > > the deployment classloader being associated with every
> > deployable item for
> > > further resolution would IMHO be a better design.
> > >
> > > Best,
> > > CGJ
> > >
> > >
> > >
> > >
> > >
> >
> > > ATTACHMENT part 2 application/octet-stream name=AxisServlet.diff
> >
> >
> > > ATTACHMENT part 3 application/octet-stream
> > name=ClassLoaderAwareMessageContext.java
> >
> >
> > > ATTACHMENT part 4 application/octet-stream
> > name=ClassLoaderAwareAxisServer.java
> >
> >
> > > ATTACHMENT part 5 application/octet-stream
> > name=AxisServiceServlet.java
> >
> >
> >
> > =====
> > Davanum Srinivas, JNI-FAQ Manager
> > http://www.jGuru.com/faq/JNI
> >
> > __________________________________________________
> > Do You Yahoo!?
> > NEW from Yahoo! GeoCities - quick and easy web site hosting,
> > just $8.95/month.
> > http://geocities.yahoo.com/ps/info1
> >