tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Resources - merging back the changes
Date Tue, 23 Oct 2012 10:53:09 GMT
On 23/10/2012 01:01, Konstantin Kolinko wrote:
> 2012/10/17 Mark Thomas <>:
>> On 17/10/2012 15:07, Konstantin Kolinko wrote:
>>> 1. Are <PreResource> and <PostResource> able to inject individual
>> Not yet, but that should be relatively simple to implement.
>>> 2. I am -1 on removal of VirtualWebappLoader.
>>> The feature of injecting additional classpath entries into
>>> WebappClassLoader.super.addURL() is an important one and I use it a
>>> lot to inject external dependent libraries into web applications.
>>> I do not like your approach as a replacement, because classpath
>>> entries handling (jars handling) in URLClassLoader and in
>>> WebappClassLoader is based on different requirements. I think that
>>> URLClassLoader serves better for external libraries
>> Could you expand on this please. I'm struggling to see the difference
>> between using the VirtualWebappLoader and mapping JARs into WEB-INF/lib
>> and directories containing classes onto WEB-INF/classes
> There is a difference,
> but after thinking about it I am removing my veto.

OK. Thanks. I might start porting this back quite soon as I have some
test cases I want to write that would be a lot easier with the new

> 1. If I consider the following two operations
> a. adding a library to the classpath
> b. maintaining it as a proper webapplication resource
> if "a." is all that I need, then having (a. + b.) will have an
> additional overhead.

Yes, there is an additional overhead. Exactly what that overhead is will
vary on a case by case basis and I'd hope was at least partially
compensated for by a simpler resources implementation.

> What VirtualWebappLoader does is essentially similar to putting a
> library into  $CATALINA_BASE/shared.
> I know of the following overheads:
> 1.1.) An additional resource participates in resource lookups
> In my use case I insert a dozen of libraries into the classpath. I do
> not use VirtualWebappLoader directly, I am calling the API that it
> uses - WebappLoader.addRepository().
> Looking at the example of Tomcat 7 aliases, if you have 100 aliases
> then every resource lookup will perform a linear search through all
> the aliases.
> Regarding my question of injecting individual files into resources -
> maybe it would be better to support collections of individual files
> rather than files themselves. E.g. wrap a dozen of libraries into
> single collection for "/WEB-INF/lib".

You could place all the JARs you wanted to map in a single directory and
map that although if you want a single, central library of JARs from
which to work from you'd need a custom ResourceSet implementation which
should be pretty simple for the situation you describe.

> This way the individual libraries will be enumerated only when one is
> searching for something with a prefix of "/WEB-INF/lib". Searching for
> any other prefix will skip the libraries.

Agreed, with a custom ResourceSet.

Rather than a custom ResourceSet, the ResourceSet implementation could
be part of the standard distribution.

> 1.2.) WebappClassLoader#closeJARs(..)
> WebappClassLoader closes unused JARs after some time of inactivity.
> Discussed here:
> I do not see much sense in this jar closing feature. Anyway,
> URLClassLoader keeps its jars open.
> (Not much of an issue, though. If it were a real nuisance, we can make
> it configurable).

It is probably worth some svn archaeology to see if we can figure out
why this feature was added in the first place.

> 2. There will be small difference with handling of
> VirtualWebappLoader#setSearchVirtualFirst( ) property.
>  With VirtualWebappLoader and searchVirtualFirst=true the order of
> precedence when looking of a class is
>    {external classes and libs, webapp classes, webapp libs}.
> With webresources I think the order will be different, because
> WEB-INF/classes takes precedence over WEB-INF/lib:
>    {external classes, webapp classes, external libs, webapp libs}.
> It is a little nuance. I do not think there will be much confusion from it.




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

View raw message