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 "Jung , Dr. Christoph" <ch...@infor.de> on 2001/10/05 10:28:40 UTC

AW: Patch for Context Class Loader problems

Hi there,

I still do not understand what your usual deployment scenario is ... so I´d
like to
present a similar on to our JBoss.net idea to find out whether that is
compliant with 
the JRun requirements.

Bootclasspath BCP hosts servlet.jar and the complete webcontainer (e.g.,
jetty, jrun, ...).

axis.jar is deployed in a classloader CL1 that is a child of the
bootclasspath BCP. CL1 is the context classloader of the axis web
application starting a central AxisServlet/AxisServer in the webcontainer.
 
Concrete web-services (Java classes, Serializers and De-Serializers,
additional providers and handlers, and ... axis deployment descriptors)
wsone.wsr and wstwo.wsr are deployed in classloaders CL2 and CL2 that are
children of CL1, but otherwise not necessarily related.

So the classloader structure will look like:

  BCP (System)
   |
  CL1 (Web-App)
 /  \
CL2 CL3 (Web-Services)

and the context classloader that your webcontainer will present you (if at
all as we have learned from the
previous patch requests) will be most likely CL1, right?

I hope that this example illustrates my previous postings: The generic Axis
code should be prepared that the plugged-in classes
(handlers,de-serializers, providers, targets) reside in sub-classloaders to
the context classloader, hence
MessageContext.classLoader!=Thread.currentThread().getContextClassLoader(). 

IMHO, the information which deployed items belong to which classloader must
be stored and retrieved explicitely in/from the AxisEngine. 

CGJ