Hi Tony;
pls see my comments below;
Thanks,
Deepal
................................................................
~Future is Open~
----- Original Message -----
From: "Tony Dean" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, December 06, 2005 8:31 PM
Subject: RE: [AXIS2] classloader issues/possible enhancements
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.
+1 , send us the patch
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.
I have implemented that in first place , I mean if the service is an
archive file first I exploded that and then using that I create a URL class
loader and do my works , but there was an argument in the mailing list on
this and finally we decided not to do that. I have idea to implement URL
getResource(); and I think the way I m thinking is correct I will do it soon
and commit that .
-----Original Message-----
From: Deepal Jayasinghe [mailto:[EMAIL PROTECTED]
Sent: Monday, December 05, 2005 11:00 PM
To: [email protected]
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 -----
From: "Tony Dean" <[EMAIL PROTECTED]>
To: <[email protected]>
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
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
attribute
private String[] class_delegation_filter = {
"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 = (Class) loadedclass.get(name);
if (c != null) {
if (resolve)
resolveClass(c);
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;
break;
}
}
}
if (!parent_first_delegation) {
// try to find the class locally
try {
c = findClass(name);
if (resolve)
resolveClass(c);
}
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,
/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
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?
Thanks.
Tony Dean
SAS Institute Inc.
919.531.6704
[EMAIL PROTECTED]
SAS... The Power to Know
http://www.sas.com
