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.caldar...@unisys.com> > >>> From: Mark Thomas [mailto:ma...@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-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >>
smime.p7s
Description: S/MIME cryptographic signature
