tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Williams <nicho...@nicholaswilliams.net>
Subject Re: JarScanning
Date Thu, 21 Feb 2013 18:36:15 GMT

On Feb 21, 2013, at 10:42 AM, Romain Manni-Bucau wrote:

> Hi,
> 
> the best IMO would be to have a WEB-INF/tomcat.properties with the ability
> to configure the scanner + its properties (thanks a prefix) from the webapp
> itself
> 
> PS: META-INF/context.xml would work too but i'm not a fan of xml ;)

My $0.02 here, as unbinding as it may be... :-)

I made the suggestion some time ago [1] to create support for a /WEB-INF/tomcat-web.xml file
similar to the ones for GlassFish, WebLogic, WebSphere, Geronimo, [I could go on...] that
provided the ability to customize the JSP compile level (1.6, 1.7, 1.8, etc.) and also to
specify that Tomcat should precompile all JSPs as part of deploying the web app. Such a file
could also be used for specifying jarsToSkip/jarsToScan properties. This could be useful for
portability (our application at work has *.xml files for each major AS, but then have to tell
our Tomcat-using customers how to change the compile level of their JSPs, which also affects
any other applications that they are running). I was actually thinking lately about maybe
implementing it myself (with feedback from y'all on design) and then offering a (albeit large)
patch to resolve the suggestion.

Two opinions:

- It should be XML, not properties. I share Romain's general dislike for XML, but the advantage
of using that over properties is that IDEs and other tools (possibly at application build
time) can reference a schema and validate the validity of that schema, thereby ensuring ahead
of time that they contents of it haven't been fat-fingered.

- It should be a separate XML file from /META-INF/context.xml. The possible applications of
this file are huge and could continue to expand. The concept of the context.xml file has a
specific relation to the Tomcat configuration, and I don't believe that we should have a bunch
of properties that are only valid for applications and not for Tomcat globally muddying the
concept of the context.xml file. Users could easily see compilerTargetVM, compilerSourceVM,
precompileJsps, and/or jarsToSkip in an application's /META-INF/context.xml file and think
those can also be copied to [Tomcat Home]/conf/context.xml and have an effect globally (when
in reality they are configured elsewhere or not at all, as in the case of precompileJsps).
I think the settings that only apply to an application and don't apply globally should be
in a separate file, not in /META-INF/context.xml.

Like I said, just my $0.02.

[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52924

> 
> 
> 
> 2013/2/21 Caldarale, Charles R <Chuck.Caldarale@unisys.com>
> 
>>> From: Mark Thomas [mailto:markt@apache.org]
>>> Subject: JarScanning
>> 
>>> jarsToScan
>>> This is a little more complicated.
>>> First of all, how does it work? The suggestion is:
>>> - If jarsToScan matches, scan it
>>> - else if jarsToSkip matches, skip it
>>> - else scan it
>> 
>> From the above, it looks like the only purpose of jarsToScan is to avoid
>> checking the jarsToSkip list.  Unless such checking is expensive, this
>> seems like an unnecessary complication.
>> 
>> - Chuck
>> 
>> 
>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
>> MATERIAL and is thus for use only by the intended recipient. If you
>> received this in error, please contact the sender and delete the e-mail and
>> its attachments from all computers.
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>> 
>> 


Mime
View raw message