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