Tony, i'd say please submit a patch. please run "svn diff" from the root directory, zip up the output and upload it to jira.
thanks, dims On 12/6/05, Tony Dean <[EMAIL PROTECTED]> wrote: > 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 > > > > -- Davanum Srinivas : http://wso2.com/blogs/
