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
>
>
>