tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <rainer.j...@kippdata.de>
Subject Re: Supporting more general globs in loader definition?
Date Thu, 23 Jun 2011 16:29:43 GMT
And this would be the patch:

http://people.apache.org/~rjung/patches/tc7-loader-glob.patch

Regards,

Rainer

On 23.06.2011 16:39, Rainer Jung wrote:
> On 23.06.2011 16:34, Rainer Jung wrote:
>> At the moment the file globs we support in the loader definitions in
>> catalina.properties are hard coded to DIRECTORY/*.jar.
>>
>> Sometimes it would be helpful to allow a bit more flexible globs, like
>> e.g. log4j-1.2.*.jar or similar.
>>
>> Would there be any interest if I would investigate whether we can use
>> e.g. the DirectoryScanner from ant to support more general globs?
>>
>> Since we want to define the loader path, we only want to end up with
>> directories and jar files. So one idea would be to filter the result of
>> the DirectoryScanner to only include dirs and jars that match. If we
>> find that more secure, we could also restrict to jars only, because I
>> think that's the most probable use case for globs and picking up any
>> dirs e.g. when using a recursive pattern might not be what the user
>> expected.
>>
>> The result should be compatible to what the users got when using the
>> strict *.jar pattern.
>>
>> Since we scan the directories only on startup and the ant code is
>> mature, I don't expect any problematic performance impact.
>>
>> I don't have a patch yet, but wanted to check for general feedback
>> before investigating more deeply.
> 
> Sent a bit to quickly:
> 
> A much simplr solution would be using the Matcher util class we already
> imported from ant to support globs in the jar scanner skip list. If we
> only allow the globs to be part of the file name, then the impl would be
> pretty straightforward using the Matcher. Globs in the file name and not
> the directory part is the most important use case and easy to understand
> in its consequences. So I lean towards this type of improvement right now.

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


Mime
View raw message