On 23.06.2011 19:46, Konstantin Kolinko wrote:
> 2011/6/23 Rainer Jung <rainer.j...@kippdata.de>:
>> 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.
>>
>> Regards,
>> Rainer
>
> So, you are talking about common.loader, shared.loader, and
> server.loader values in catalina.properties file.
Yes.
> (I somehow thought it was about jarsToSkip).
I added globs there for TC 7.0.3.
> It is hard to find a use case for this feature you are asking for.
I will explain below.
> The only use case that comes to my mind is to prioritize some jars
> over the others.
> E.g. to put ${catalina.base}/lib/patch-*.jar ahead of the other
> *.jars in the same directory. Though it does not differ much from
> using ${catalina.base}/lib/patches/*.jar
Yeah, I didn't think about that one.
> So, technically I do not mind allowing any name prefix before *.jar. I
> do not think there should be more wide glob support, like allowing '?'
> or '*' in any position in the name. Do you have a use case for globs?
>
>
> Politically, I do not like to have much emphasis on the
> "common.loader" property.
>
> I expect the list of jars to be put in "common.loader" to be rather
> short. You put there the jars used by Tomcat, the jars used by
> components declared in server.xml and context files, database drivers.
>
> People should really put everything else into WEB-INF/lib, or use a
> VirtualWebappLoader.
Agreed.
> As an example of a mess: using the pattern "log4j-1.2.*.jar" from
> your example it is easy to select several versions of Log4J, which
> might result in a disaster. If there is only one version of log4j,
> why not to copy or symlink it into designated directory? Thus all the
> libraries will be in one place and will be easier managed.
See below, it is about updating.
> One more note:
> I recently added support for arbitrary system properties expansion in
> the value of common.loader and other *.loader properties. As a side
> effect it is now possible to use whatever Unix command (e.g. find) in
> setenv.sh to build a list of jars and define it as a system property.
I saw that, a great improvement.
> Summarizing: I do not mind to add support for name*.jar, but will
> think twice about anything else.
The only concrete example I have in mind is about adding log4j to Tomcat
to let it log via Log4J.
Here the situation I'm thinking about is a split CATALINA_HOME vs.
CATALINA_BASE installation. Log4J is provided in some extra directory of
CATALINA_HOME using the normal jar file name, e.g. log4j-1.2.16.jar.
The jar will be referenced from catalina.properties in CATALINA_BASE not
using a *.jar pattern, because in the extra dir there is a couple of
jars, some you want to include, some not.
Now when CATALINA_HOME is updated, there might be a new version of log4j
(not: multiple versions) and the entry in catalina.properties does no
longer match, leading to Tomcat using java.util.logging instead.
Of course there are several solutions:
- installing log4j in a directory not used for other jars, so one can
use *.jar
- installing the log4j jar under a name, that does not include the version
- Fixing the entry in catalina.properties as part of the update
- Ignoring the problem, because there might never be another version of
log4j after 1.2.16
But supporting a glob in the file name would also work.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
