You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Matt Bowersox <mb...@rochester.rr.com> on 2002/01/31 22:54:58 UTC

Could we please take a second and discuss AxisClassloader (3rd attempt)

I have attempted to engage the list on this issue on two seperate occasions
and have recived no feedback. The implementation decisions made in the
design of this  class completely breaks axis on ATG dynamo ( a certified
j2ee app server) and possibly other vendor's products.

ps.  sorry if the obtuse numeric email address in some of my prior messages
is  confusing, I am sometimes trapped behind our clients firewalls and it
can do weird things to email addresses.
please respond to the list or the mbowers2@rochester.rr.com addresses for
personal correspondances.

----- Original Message -----
From: <96...@knotes.kodak.com>
To: <ax...@xml.apache.org>
Sent: Monday, January 28, 2002 2:12 PM
Subject: possible bug


> From: Matthew Bowersox
>
> The axis classloader is based on a parent classloader derived from the
> thread context. I suspect that the assumption that the classloader derived
> from the thread context should be able to load the j2ee web container
> classes for axis is false. This behavior  breaks axis on the atg dynamo
> version 5.5 application server. I patched AxisClassLoader  by having it
> instantiate a class in an axis package, then  calling getClass
> ().getClassloader() on this axis packaged class as a way to ensure gaining
> refererence to the j2ee application classloader. the servlet spec is
> somewhat fuzzy in this regard. it manadates a sperate clasloader for each
> j2ee app but does not specify the required mechanism to gain a reference
to
> it. and certainly does not prescribe that the current thread object  use
> the same classlaoder as it is quite conceivable that the thread object be
> part of the application server proper not a particular web container.
>
> thoughts?
>
>
> Matt Bowersox
>
>
>