Hi Exactly, same for tld would be possible! The idea is more or less to start from xbean then create a kind of commons-scanner. Would be great to get it in Tomcat itself. Le 14 juin 2013 05:06, "Nick Williams" <nicho...@nicholaswilliams.net> a écrit :
> > On Jun 13, 2013, at 11:23 AM, Mark Thomas wrote: > > > As I make my way through the Servlet 3.1 spec reviewing all the changes > to make sure they have all been implemented, I have reached section 8.2. > There are a number of related issues here. > > > > 1. Three known issues with the current SCI / fragment handling [1] > > - SCI scan does not obey class loader ordering > > - fragments in container JARs are processed > > - Container SCIs may be exluded > > > > 2. A wish for per context jarsToSkip [2] > > > > 3. A wish for greater control over jarsToSkip [3] > > > > > > These issues are all inter-related. Fixing them is going to require > either some very ugly hacks or changes to the JarScanner API. > > > > I have started down the route of the JAR scanner API changes. The > overall idea is: > > - jarsToSkip is replaced by a JarScanFilter with the default > > implementation doing what jarsToSkip currently does > > I would request "doing what jarsToSkip currently does plus what is wanted > with jarsToScan in 3." It shouldn't be extra complicated or require re- or > duplicate-configuration of anything to whitelist one JAR. > > Also, it's very important that log4j-core*.jar and log4j-taglib*.jar be > whitelisted by default. These are 2.0-specific JARs and they must be > scanned. log4j-core contains listeners/filters/fragment to initialize and > deinitialize in a Servlet container properly, and log4j-taglib contains a > TLD. > > Nick > > > - The client passes the type of scan (TLD, Pluggability, etc) to the > > JarScanner > > - The JarScanner indicates whether or not any JAR found is an > > application or container JAR > > - The JacScanFilter filters the JARs returned based on scan type and on > > configuration > > > > This addresses the above issues in the following way: > > 1 - Knowing if the JAR is a container JAR or not allows the > > ContextConfig class to do the right thing. > > 2 - The StandardJarScanFilter can be configured per context in the same > > way the StandardJarScanner can. > > 3 - Same as 2. > > > > The StandardJarScanFilter will have enough options to implement the > requirements of 2 & 3. > > > > I currently have the start of this in a local git repo. Any objections > to me committing what I have to trunk and continuing there? > > > > > > [1] http://markmail.org/message/22e3sjmsy2gt4tkw > > [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=54083 > > [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=54770 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
