tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Refactoring class loader access to resources
Date Tue, 24 Sep 2013 13:12:13 GMT
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?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message