axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Dean" <>
Subject RE: [AXIS2] classloader issues/possible enhancements
Date Tue, 06 Dec 2005 14:31:51 GMT
Adding a classes/ directory sounds good... more webapp centric. It sounds like we are on the
same page here.  Do you still need me to provide you a patch?  If so how do I do that besides
just giving you the updated source files.

What about the archive model and implicit exploding of lib/*.jars in order to be able to find
resources?  Are you in agreement here as well.

-----Original Message-----
From: Deepal Jayasinghe [] 
Sent: Monday, December 05, 2005 11:00 PM
Subject: Re: [AXIS2] classloader issues/possible enhancements

Hi Tony;

I 100% agree with you about the fact you suggested , when I was writing the class loader I
did not so much think about those and in the mean while there were no many users who using
that . Therefore we did not find bugs in the code ( :) ). Now we are finding bugs and improvements
,so I think the best way is to have the parent-last scenario and per service there will be
a parameter to change that if some one wants (I mean parent first or parent last).

At the same time I am thinking of putting classes directory into both exploded and archive
files , rather than putting classed files starting from package name  , the current structure
is like below

but what I feel is we have to change this a bit and have the following structure , since that
is more self explained.

Therefore I think its better use only the deployment class loader , rather than using URLClassLoader

~Future is Open~

----- Original Message ----- 
From: "Tony Dean" <>
To: <>
Sent: Tuesday, December 06, 2005 3:11 AM
Subject: [AXIS2] classloader issues/possible enhancements


I have been looking at several things that can be improved here.

* I am experiencing loading problems with both the exploded model and 
archive model (.aar file).

The main problem here is that both my application and Axis distribute log4j. 
Because of normal classloader delegation, my application usage of log4j 
causes log4j classes to be loaded by the WebAppClassLoader, not the 
URLClassLoader (classloader that loads my application).  Then when log4j 
tries to create a custom layout (part of my log4j extension), my custom 
layout class cannot be found.  I'm sure there may be other issues that could 
arise in the future as well.

To get around this problem, I use the DeploymentClassLoader and extend it by 
adding loadClass().  In this method I choose to find classes in my 
application first, before delegating to the parent classloader (i.e., 
WebAppClassLoader).  It works nicely.  We could make this a configurable 
Axis2 option (parent_first or parent_last) for the DeploymentClassLoader.  I 
think it is reasonable for each web service to want to load its specific 
classes before delegating to the WebAppClassLoader so I'd like to see the 
default behavior being parent_last.  Of course loading of certain classes 
should always delegate to the parent (e.g., java.*, javax.*, 
org.apache.axis.*, etc...).

ArchiveFileData will need to be changed so that both exploded and archive 
model use the DeploymentClassLoader in order to take advantage of this 
classloading feature.

Sample code (DeploymentClassLoader):

     * Override class loading policy to use "PARENT_LAST" scheme so
     * that application classes are loaded first before delegating
     * to the parent classloader.
    private boolean parent_first_delegation = false; // make configurable 
    private String[] class_delegation_filter = {

    public Class loadClass(String name) throws ClassNotFoundException
    return loadClass(name, false);

    protected synchronized Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
    // check previously loaded local class cache
    Class c = (Class) loadedclass.get(name);
    if (c != null) {
        if (resolve)
    return c;

    // determine delegation policy for this class
    boolean parent_first_delegation = this.parent_first_delegation;
    if (!parent_first_delegation) {
        for (int i=0; i<class_delegation_filter.length; i++) {
                    String filter = class_delegation_filter[i];
                    if (name.startsWith(filter)) {
                        parent_first_delegation = true;

    if (!parent_first_delegation) {
        // try to find the class locally
                try {
                   c = findClass(name);
                   if (resolve)
               catch (ClassNotFoundException e) {

    // unconditional delegation
    c = super.loadClass(name, resolve);

            return c;

* Archive model does not find resources embedded with jars (lib/*.jar) 
within the .aar file.

This is the problem that I reported last week.  I have looked into this 
problem a little.  It seems like an easy fix, but I do not think it's 
possible to create a URL that represents a resource in a jar which itself is 
contained in a jar.  The only way that I know how to deal with this problem 
is to automatically explode these jars during deployment.  For instance,

  myWebservice.aar (file)

would get exploded as

  myWebservice.aar (file)
  myWebservice.aar (directory)
      *.jar - all jars contained in myWebservice.aar (/lib)

Then I could add myWebService.aar and its dependent jars (/lib/*.jar) to the 
URL classloader classpath.

The URLClassloader loader could now take care of loading classes and 
resources in .aar and its dependent jars.  The DeploymentClassLoader could 
be dumbed down a little and not have to worry about these dependent jars 
anymore.  ArchiveFileData would need to be enhanced for this to happen.

What do you guys think about these issues?


Tony Dean
SAS Institute Inc.

SAS... The Power to Know

View raw message