On 19/02/2015 07:17, Pravallika Peddi wrote: > Hi Mark, > Below are my observations during my research on the bug: > > 1) I downloaded recent trunk and ran the ant command so that the > build/bin/lib folders are generated. > > 2) I created a simple web application and exported to WAR file which is of > 3.4 MB size including 10 required jar files. > > 3) I enabled debugging as mentioned in bug: > org.apache.tomcat.util.scan.StandardJarScanner.level = FINE > org.apache.catalina.startup.Catalina.level = INFO > > 4) I deployed the WAR file using trunk/output/build/bin/catalina.bat file. > Deployment is successful and i could see my application running. > > One Log message observed is: > 19-Feb-2015 04:30:45.958 INFO [localhost-startStop-1] > org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned > for TLDs yet contained no TLDs. Enable debug logging for this logger for a > complete list of JARs that were scanned but no TLDs were found in them. > Skipping unneeded JARs during scanning can improve startup time and JSP > compilation time. > > 19-Feb-2015 04:30:47.144 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in 2680 ms > > Even though i kept 10jars only 5 jars got scanned and don't see the issue > reproduced. > > My assumptions on Bug: Deploy simple WAR taking longer time due to tomcat > 7.0 JAR scanning is taking more time.
Correct. > Enhancement requested is: If some jar file is missing then add a log > message in log file saying "add it under JarsToSkip". There are multiple reasons a JAR can be scanned and different properties to control which scans it is included in / excluded from. The properties that control the scanning process changed between 7.0.x and 8.0.x. 8.0.x also introduced the JarScanFilter configuration element. > Please correct me if my understanding about the bug is wrong. It isn't quite as simple as it looks. There are different views about what should appear by default. I'd suggest you aim for the following (some of which may already be implemented). 1) By default, no more than 1 log message per type of JAR scan (TLD, Pluggability) per web application stating that one or more JARs were scanned unnecessarily and that Tomcat could be configured to skip them in future. Include details of how to get the full list of JARs if required and what configuration option to change. 2) A simple way to enable additional logging to log each JAR and scan type combination that was unnecessary. This additional logging should not 'hide' the JAR/scan details and in a pile of other log messages. 3) Review the list of JARs in that bug to see which ones should be added to which JAR scan skip option - if any - by default. The solution for trunk and 8.0.x is likely to be different than the solution for 7.0.x. A quick look at the code suggests that the TLD scanning is pretty much there (but you should check it). The pluggability scanning isn't and it is harder to determine which JARs can be skipped because there are multiple things the JARs are checked for in different places. This could get messy if you aren't careful. I suggest you come up with a proposal and run it past the dev list before you go to far with development of this. Mark > > Thanks, > Pravallika(VIN) > > On Wed, Feb 18, 2015 at 12:30 PM, Pravallika Peddi <reachme.va...@gmail.com> > wrote: > >> Sure Mark, I will try and let you know. >> >> >> On Tue, Feb 17, 2015 at 4:20 PM, Mark Thomas <ma...@apache.org> wrote: >> >>> On 17/02/2015 06:42, Pravallika Peddi wrote: >>>> Hi Mark, >>>> Its regarding the another bug that you shared to me: >>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=56438 >>>> >>>> This bug involves migration from 5.5 to 7.0, and i am new to migration >>> of >>>> Tomcat releases. Hence can you assign me some other issues which can >>> handle >>>> with code directly? >>>> >>>> Or please let me know the search criteria to find out the right issues >>>> based on my expertise. >>> >>> Do some more research on that issue. Migration was just the point in >>> time where the user discovered the issue with the current Tomcat >>> behaviour. You should be able to replicate the problem with a very >>> simple web application with trunk (or just add JARs to one of the web >>> applications that ships with Tomcat). >>> >>> Mark >>> >>> >>> --------------------------------------------------------------------- >>> 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
