On Mon, 2005-12-05 at 16:11 -0500, Tony Dean wrote: > 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). ... > > 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.
+1 for this; please submit a patch! :) > * 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, Deepal, I thought you mentioned that this was already working .. can you please clarify the status? > /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. I'm not a fan of always exploding because that makes assumptions about the form of the repository. It is feasible that the repo is in fact a database .. in that case we can't do directory explosion as easily. I'd like to push a bit more and see whether we can get it to work right first before taking such a binding step. Sanjiva.
