tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
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 <markt@apache.org>:
>> On 17/10/2012 15:07, Konstantin Kolinko wrote:
>>
>>> 1. Are <PreResource> and <PostResource> able to inject individual
files?
>>
>> 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
implementation.

> 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:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52448
> 
> 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.

Agreed.

Cheers,

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message