Hi Mark,
Sorry, I was on long vacation due to which I could not respond immediately
on bug: https://bz.apache.org/bugzilla/show_bug.cgi?id=56438
*Below are my further observations on Tomcat7.0 trunk:*
1) As mentioned in bug, in Tomcat7.0 catalina.properties file first 4
default jars(except jdom.jar) are missing:
commons-discovery-*.jar,commons-el-*.jar,commons-net-*.jar
We can add them under
“tomcat.util.scan.DefaultJarScanner.jarsToSkip”
2) I observed that all the remaining jars are processed for TLDs
and Context configs.
When I add those jars under
“org.apache.catalina.startup.TldConfig.jarsToSkip” and
“org.apache.catalina.startup.ContextConfig.jarsToSkip” they are getting
skipped from processing.
3) 3) So I am planning to provide a fix as below for Tomcat 7.0
TLD scan:
*org.apache.catalina.startup.TldConfig.java à tldScanJar(JarURLConnection
jarConn) method à** introduce a Boolean variable called isTldFound as
below:* *boolean isTldFound = false;*
*Set this variable to true in below case(when tld found in jar):*
* if (entryName.startsWith("META-INF/") &&*
* entryName.endsWith(".tld")) {*
*isTldFound
= true;*
*After the while loop ends(processed all entries of jar), add
below code:*
*if(!isFound){*
* if (log.isDebugEnabled()) {*
*
log.info(sm.getString("tldConfig.noTldInJar",*
*
jarConn.getURL().toString()));*
* }*
* }*
Here tldConfig.noTldInJar = No TLD files were found in [{0}]. Consider
adding the JAR to the org.apache.catalina.startup.TldConfig.jarsToSkip
property in CATALINA_BASE/conf/catalina.properties file.
This message will be printed at FINE level. So unless user enables Debug
mode, he can not see the noTldInJar message.
This message was taken from 8.0 trunk.
*In Tomcat 8.0 trunk, we print a info Summary message to warn the user
saying “Atleast one jar was scanned …” Since in 8.0 both TLD and
ContextConfig are having two different approaches we can add that.*
But in Tomcat 7.0, StandardJarScanner.scan method only called from both
TldConfig.java and ContextConfig.java. So I am afraid I cannot add the
Summary message in Tomcat7.0. When User enables FINE level then only they
can see the noTldInJar messages
4) Tomcat7.0 ContextConfig scan is taking less time, hence I feel we can
ignore it for now.
Please let me know your opinion.
On Thu, Feb 26, 2015 at 12:59 AM, Mark Thomas <ma...@apache.org> wrote:
> On 25/02/2015 11:46, Pravallika Peddi wrote:
> > Hi Mark,
> >
> > More updates on bug 56438:
> >
> > I have downloaded all the jars mentioned in the issue
> > except(Protomatter.jar, openspml2-toolkit.jar, ha-jdbc.jar, db2jcc4.jar,
> > hazelcast.jar) and added import statements in my web application for
> these
> > jars.
> >
> > I have added couple of more log messages for my research purpose in trunk
> > code of 8.0.x and 7.0.x and observed that,
> >
> > With 8.0.x trunk:
> > 1) All Jars got scanned for PLUGGABILITY and TLD's.
>
> Are you sure? Check the metadata-complete setting of the app you are using.
>
> > 2) After Pluggability scan, i do not see any log message stating
> "Atleast
> > one jar was scanned having no fragments and it is unnecessary to scan
> this
> > jar". Not sure whether it is expected or not.
> >
> > 3) For TLD scan, i could see a message stating "Atleast one jar was
> > scanned without TLD's. Enable debug logging provides more details on
> which
> > jars got scanned for TLDs.". When i enable "Debug" mode, i could see
> > messages stating "No TLDS were found in file:jar path. Consider adding
> this
> > to the tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
> > CATALINA_BASE/conf/catalina.properties file".
> >
> > With 7.0.x trunk:
> > 1) All Jars got scanned for TLDs. Seems Pluggability scan was not there(I
> > did not find the code for it. Correct me if i am wrong)
>
> The code is there. Look in ContextConfig.
>
> > 2) Afetr TLD scan, I do not see any message stating "No TLDs were found
> in
> > a jar" even with debug mode enabled.
> >
> >
> > My action items based on your confirmation:
> >
> > For 8.0.x trunk:
> > 1) For Pluggability scan, add code in such a way that it prints "No
> > Fragments were found in Jar. Hence add it under some filter in
> > catalina.properties file to avoid future scanning.
> >
> > 2) For TLDs: Nothing is required.
> >
> > For 7.0.x trunk:
> > 1) For TLD scan, add proper log message as in 8.0.x trunk for TLD not
> found
> > jars.
> >
> > Please add your suggestions.
>
> That looks like a good place to start. The tricky bit will be how you
> mark a JAR as 'skippable'.
>
> Mark
>
>
> >
> > Regards,
> > Pravallika(VIN)
> >
> > On Mon, Feb 23, 2015 at 2:46 PM, Pravallika Peddi <
> reachme.va...@gmail.com>
> > wrote:
> >
> >> Sure Mark. I am doing the research.
> >>
> >> On Thu, Feb 19, 2015 at 3:11 PM, Mark Thomas <ma...@apache.org> wrote:
> >>
> >>> 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
> >>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>
