On 05/08/2010 11:38, Rainer Jung wrote: > On 04.08.2010 22:47, Mark Thomas wrote: >> I'm happy to see all of this configuration completely re-written if that >> is what is required. That said, this is just a start-up optimisation. >> >> I think we need three groups: >> a) never scan (JAR or TLD) >> b) default jarsToSkip >> c) default noTldJar >> >> I'd suggest all three being set in catalina.properties with b)& c) >> over-ridable per context. Users can over-ride the defaults in >> catalina.properties if they wish. > > OK, let's focus on this. Using full paths or not can be discussed later. > > Concerning the per context config: > > jarsToSkip and noTldJar are both consumed by the JarScanner. But since > the JarScanner is very generic, I hesitate a bit adding separate setters > for noTldJar and jarsToSkip to the JarScanner. > > So options are: > > 1) We can go with only one setting used for both use cases. > > 2) Forget about the abstract value of the JarScanner and simply add both > setters there. > > 2a) Keep posibility to override the setting by the exsting argument > in scan method (called by ContextConfig, TldConfig or TldLocationsCache) > > 2b) Remove posibility to override the value scan method (called by > ContextConfig, TldConfig or TldLocationsCache) > > 3) Add only jarsToSkip setter to JarScanner (used for the web fragments > scanning) and assume/make noTldJar configurable at TldConfig and/or > TldLocationsCache (I don't know yet the mechanics of those two). > > 4) Make jarsToSkip and noTldJars configurable outside the JarScanner and > always passed in via the scan method. jarsToSkip possibly as part of the > top level context config, noTldJars yet unknown to me. > > I tend for 2) and maybe 2b but don't know enough about possible use > cases of 2a).
I'd lean toward 4 with both skipTldJars & skipWebFragmentJars configured on the Context and passed to the components that need it. > Another thing: still time to make the two names more consistent? Like > "skipTldJars" and "skipWebFragmentJars" (and "skipAlwaysJars"). +1 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
