axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: Bug 17347 - Provider Lookup Fails within EARs
Date Mon, 03 Mar 2003 20:31:40 GMT

----- Original Message -----
From: "Jens Schumann" <jens@void.fm>
To: <axis-dev@ws.apache.org>
Sent: Monday, March 03, 2003 11:26
Subject: Re: Bug 17347 - Provider Lookup Fails within EARs


> On 3/3/03 06:14 PM Steve Loughran <steve_l@iseran.com> wrote:
>
> >
> > ooh, first we have to enum the problems with different platforms.
> >
> > Tomcat: endorsed versus non-endorsed dirs on java1.4
> > SunOne: recent postings about its contextClassloader being invalid
> > WebLogic: doesnt explode WARs into directories, so whenever we ask for
the
> > physical path to something in the webapp, we get failure.
>
> Hmm.
> I think we should to take a look at classloader hierarchies found on these
> platforms first. (I might be a little bit off the actual implementation -
> since I am writing this out of my head).

>
> So why did I spend that much time explaining class loading mechanisms? ;)
> Because I would show that there is nothing you can be sure of while
calling
> getClass().getClassLoader() or currentThread().getContextClassLoader().

yup. Also there is ServletContext.getResource() and
ServletContext.getResourceAsStream() to worry about.

>
> If somehow someone put axis.jar in the system classpath and uses weblogic
or
> websphere, it will be tough to access a resource inside the war.

dont do that then :) CLASSPATH should be empty. And axis must never go into
JRE/ext. If people mess with the classpath outside the webapp then its their
own faulut.

>Same
> applies to referenced modules inside Websphere. Ear deployment on bea 6.x
> will force you in certain situations to reference or add all war archive
> classes to all ejb archives, otherwise you will run into
> ClassNotFoundExceptions.

> But - this also means that your this classes will
> be loaded by the EAR classloader, not through the war archive classloader.
I
> don't know why, but using the exploded axis web archive on JBoss forced me
> to copy the servlet classes in its WEB-INF/lib, otherwise usage of the
admin
> servlet would fail. But servlet classes are part of lib/ and should be
> accessible through the shared repository.

hmmm. That does sound wierd. File a bug with axis and jboss.

>
> So what do I recommend? Avoid using getClassloader().getResource() in web
> archives at all ;).

I find it has a useful place. I keep a lot of my config stuff in the WAR,
and dont encounter your problems. Example: Axis1.1 lets you provide the path
to the WSDL resource for the ?wsdl response.

The problem is choosing which classloader to use. We could consider
standardising on ServletContext.getResourceAsStream(), as it doesnt have to
be a classloader at all. Or we have a method
AxisEngine.getResourceAsStream(String path) that tries the ServletContext
call first, then its own classloader if that fails to find resources. At the
very least, it would give us a single place to instrument and toy with when
trying to fix future problems.


> And btw - hot redeployment and JNDI object registration
> makes things much worse ;).

yes, there is nothing like an old object instance being serialised somewhere
to hurt you.


> > Attachments can be configured to go somewhere else, I believe
> Yes, but default will be inside the war.

that should be fixed. Even if we fix class loading, we should eliminate
writing to the war space.


Mime
View raw message