Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: domain of Tony.Dean@sas.com designates
 149.173.6.5 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [AXIS2] classloader issues/possible enhancements
Date: Tue, 6 Dec 2005 09:31:51 -0500
Message-ID: <C82BC4942490674D94ADE0E07683C9670354505A@MERC27.na.sas.com>
Thread-Topic: [AXIS2] classloader issues/possible enhancements
Thread-Index: AcX6GagGHXid1mqiSkCVGst+IrSn9AAV0Qyw
From: "Tony Dean" <Tony.Dean@sas.com>
To: <axis-dev@ws.apache.org>

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 [mailto:deepal@opensource.lk]=20
Sent: Monday, December 05, 2005 11:00 PM
To: axis-dev@ws.apache.org
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
     Service
         META-INF
              services.xml
         lib
           mylib.jar
           mylib2.jar
       org
          apache
             axis2.
                   ......

but what I feel is we have to change this a bit and have the following =
structure , since that is more self explained.
   Service
         META-INF
              services.xml
         lib
           mylib.jar
           mylib2.jar
       classes
          org
             apache
                axis2.
                   ......

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


Thanks,
 Deepal
................................................................
~Future is Open~

----- Original Message -----=20
From: "Tony Dean" <Tony.Dean@sas.com>
To: <axis-dev@ws.apache.org>
Sent: Tuesday, December 06, 2005 3:11 AM
Subject: [AXIS2] classloader issues/possible enhancements


Hi,

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

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

The main problem here is that both my application and Axis distribute =
log4j.=20
Because of normal classloader delegation, my application usage of log4j=20
causes log4j classes to be loaded by the WebAppClassLoader, not the=20
URLClassLoader (classloader that loads my application).  Then when log4j =

tries to create a custom layout (part of my log4j extension), my custom=20
layout class cannot be found.  I'm sure there may be other issues that =
could=20
arise in the future as well.

To get around this problem, I use the DeploymentClassLoader and extend =
it by=20
adding loadClass().  In this method I choose to find classes in my=20
application first, before delegating to the parent classloader (i.e.,=20
WebAppClassLoader).  It works nicely.  We could make this a configurable =

Axis2 option (parent_first or parent_last) for the =
DeploymentClassLoader.  I=20
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=20
default behavior being parent_last.  Of course loading of certain =
classes=20
should always delegate to the parent (e.g., java.*, javax.*,=20
org.apache.axis.*, etc...).

ArchiveFileData will need to be changed so that both exploded and =
archive=20
model use the DeploymentClassLoader in order to take advantage of this=20
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 =3D false; // make =
configurable=20
attribute
    private String[] class_delegation_filter =3D {
    "java",
"javax",
"org.xml.sax",
"org.w3c.dom",
"org.apache.axis",
"org.apache.xerces",
"org.apache.xalan"
    };

    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 =3D (Class) loadedclass.get(name);
    if (c !=3D null) {
        if (resolve)
                    resolveClass(c);
    return c;
    }

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

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

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

            return c;
    }


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

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

/services
  myWebservice.aar (file)

would get exploded as

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

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

The URLClassloader loader could now take care of loading classes and=20
resources in .aar and its dependent jars.  The DeploymentClassLoader =
could=20
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?

Thanks.

Tony Dean
SAS Institute Inc.
919.531.6704
tony.dean@sas.com

SAS... The Power to Know
http://www.sas.com