2013/2/21 Mark Thomas <ma...@apache.org>: > An issue at work prompted me to take another look at this thread: > http://markmail.org/thread/qanw2psjsx32feek > > There are some useful things there that I think it is worth following up on. > >(..) > > 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
+1. In other words, it is a "force scan" option. > Assuming that the above is acceptable, it would require the following: > a) three new system properties > tomcat.util.scan.DefaultJarScanner.jarsToScan > org.apache.catalina.startup.ContextConfig.jarsToScan > org.apache.catalina.startup.TldConfig.jarsToScan I am not so interested in global options, but am very interested in per-webapp ones. My current thought is that a nice solution could be to have the same-named parameters in a ServletContext. So that those can be defined in WEB-INF/web.xml or using Parameter element in context.xml. >From implementation point of view though a) it will need some code to evaluate the effective value before usual merging of all web fragments has happened b) just document that the value cannot be specified in a web fragment or annotation, because of chicken vs. egg pattern. We may add a separate page to the configuration reference guide to document supported initialization parameters. E.g. websockets implementation in trunk already defines two of those, "org.apache.tomcat.websocket.binaryBufferSize" "org.apache.tomcat.websocket.textBufferSize" in org.apache.tomcat.websocket.server.Constants > b) add a parameter to JarScanner.scan() > > There are a couple of issues here. > > 1. Backwards compatibility. Adding the parameter to JarScanner.scan() > will break any custom Jar scanners. Without that parameter it would not > be possible to have different jarsToScan for pluggability and TLDs. > We do add methods to interfaces (e.g. Context), but we never remove them. I think the guidance here is that it allows a 3rd party class to be compiled for a later version of Tomcat and used with earlier ones as well. So I propose to add a second "scan" method and deprecate the first one. > 2. (and an issue with the current code [1]). These settings are all > global rather than per web application. I would prefer that they were > per web application with defaults configured globally. It is complicated > by the fact that the JARs to skip/scan may vary depending on how the > JarScanner is used. > > [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=54083 > Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
