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