Hi about the expanding, tomee forces it so an option can work. I agree with you "theorically" components shouldn't do it but in practises they have to (there is no real solutions on this side. That's why all APIs about scanning ends with a SPI :().
About addURL I think you are right too and addURL() impl can handle the conversion. About jars.txt here is the history about it https://issues.apache.org/jira/browse/TOMEE-794. In 2 words you can pu tin WEB-INF a file called jars.txt and each line represent a jar. It can be a mvn url, a http url, a file url or simply a path (with a hack for *.jar as in the virtual webapp class loader of tomcat). A part of the magic is done in start and addURL methods of http://svn.apache.org/repos/asf/tomee/tomee/trunk/tomee/tomee-catalina/src/main/java/org/apache/tomee/catalina/LazyStopWebappClassLoader.java (of course this supposes getURLs impact addURL then). Hope it is clearer *Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/9/24 Mark Thomas <ma...@apache.org> > On 24/09/2013 05:05, Romain Manni-Bucau wrote: > > Hi > > > > about the handler: a lot of container (i particularly know tomee but not > > only) use string representation of URL to find file to then work on the > > file (either during scanning or sometimes for some more advanced "hack"). > > If you introduce something not known by these framework it will just > fail. > > That's the reason why scanning is not really portable and why vfs (for > > JBoss for instance) exists. You are doing the same in tomcat (which is > sad > > since tomcat was until today simple on this aspect). > > I'd argue that components shouldn't be doing that as they have no idea > what URLs might be coming back. > > I think the way to handle this is an option on the Context (so the > default can be changed in conf/context.xml) to expand JARs from a WAR > into the work dir and generate URLs to those files if all of the > following are true: > - running in a packed WAR > - getURLs() is called > - the option is enabled > > The JARs will be deleted on context stop. > > What I am trying to avoid here is the automatic copying of resources to > the work dir. I'm also trying to ensure that all resource access goes > through WebResources as I want to add some memory leak detection code > their to catch things like InputStreams that are never closed that lead > to locked files. Having spent ages trying to track down the root cause > of a locked file, I see this sort of feature as extremely useful. In the > same way the original memory leak detection code drove improvements in > Tomcat and 3rd party libraries, I think this code do the same. > > > About addURL: we use it in tomee to enrich the classloader in multiple > > places (but i saw some tomcat extensions doing it too). Our needs are: > > 1) add container jar in a particular deployment mode (tomee as a webapp) > > 2) add container jar for some particular features (jsf, jpa, ... - some > > classes needs to be loaded from the webapp) > > 3) use a descriptor to define the container (typically jars.txt lists all > > jar of the loader with mvn/file/http/... syntax). Then our scanning just > > reuse getURLs(). > > I think this can be handled by addURL() being used to create the > appropriate dir/JAR resource and adding it to WebResources but I'm not > sure about the last one. Could you expand on that use case a little? > > Cheers, > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
