You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Pravallika Peddi <re...@gmail.com> on 2015/03/26 14:27:31 UTC
Re: Reg: Bug 56438
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.valli@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.valli@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-unsubscribe@tomcat.apache.org
> >>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Reg: Bug 56438
Posted by Mark Thomas <ma...@apache.org>.
On 08/04/2015 11:20, Pravallika Peddi wrote:
> Hi Mark,
>
>
> Highlighted code is the Fix to add summary message to *Tomcat7.0*:
Patches should be in diff -u format and are best attached to bug reports.
Mark
>
>
> In org.apache.catalina.startup.TldConfig.java à
>
>
>
> a) Return a Boolean variable from tldScanJar(JarURLConnection
> jarConn)method which indicates tld found or not.
>
> b) In TldJarScannerCallback inner class à add code a sbelow:
>
>
>
> boolean isFound = false;
>
>
>
> @Override
>
> public void scan(JarURLConnection urlConn) throws IOException {
>
> log.info <http://log.info>("Scanning jar in scan function:" +
> urlConn);
>
> isFound = tldScanJar(urlConn);
>
> }
>
>
>
> @Override
>
> public void scan(File file) {
>
> File metaInf = new File(file, "META-INF");
>
> if (metaInf.isDirectory()) {
>
> isFound = tldScanDir(metaInf);
>
> }
>
> }
>
>
>
> private boolean scanFoundNoTLDs() {
>
> log.info <http://log.info>("tldFound at end:" + isFound);
>
> return !isFound;
>
> }
>
>
>
>
>
> c) In execute() method add below code:
>
>
>
> TldJarScannerCallback objCallBack = *new*TldJarScannerCallback();
>
> jarScanner.scan(context.getServletContext(),
>
> context.getLoader().getClassLoader(),
>
> objCallBack, /noTldJars/);
>
>
>
> *if*(objCallBack.scanFoundNoTLDs()){
>
> /log/.info(/sm/.getString("tldConfig.noTldSummary"));
>
> }
>
>
>
> I tested the fix and Summary message is getting added to log.
>
> Attached the java file that contains these changes.
>
> Please review and let me know if the fix is ok or not.
>
>
> I will send another mail for pluggability scan fix details for Tomcat7.0
>
>
> Thanks,
>
> Pravallika (VIN)
>
>
> On Sun, Mar 29, 2015 at 4:07 AM, Mark Thomas <markt@apache.org
> <ma...@apache.org>> wrote:
>
> On 26/03/2015 13:27, Pravallika Peddi wrote:
>
> <snip/>
>
> > 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”
>
> jdom.jar isn't covered by the existing filters.
>
> <snip/>
>
> > 3) 3) So I am planning to provide a fix as below for Tomcat 7.0
> > TLD scan:
>
> Looks OK so far.
>
> <snip/>
>
> > 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
>
> Look again. It certainly is possible to add the summary message for TLDs
> in Tomcat 7.
>
> > 4) Tomcat7.0 ContextConfig scan is taking less time, hence I feel we can
> > ignore it for now.
>
> I disagree. The pluggability scanning can add a significant start-up
> delay to web applications. The reason that the bug report was opened in
> the first place is the time taken for the pluggability scans.
>
> > Please let me know your opinion.
>
> I think you have some more research to do.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Reg: Bug 56438
Posted by Pravallika Peddi <re...@gmail.com>.
Hi Mark,
Highlighted code is the Fix to add summary message to *Tomcat7.0*:
In org.apache.catalina.startup.TldConfig.java à
a) Return a Boolean variable from tldScanJar(JarURLConnection jarConn)
method which indicates tld found or not.
b) In TldJarScannerCallback inner class à add code a sbelow:
boolean isFound = false;
@Override
public void scan(JarURLConnection urlConn) throws IOException {
log.info("Scanning jar in scan function:" + urlConn);
isFound = tldScanJar(urlConn);
}
@Override
public void scan(File file) {
File metaInf = new File(file, "META-INF");
if (metaInf.isDirectory()) {
isFound = tldScanDir(metaInf);
}
}
private boolean scanFoundNoTLDs() {
log.info("tldFound at end:" + isFound);
return !isFound;
}
c) In execute() method add below code:
TldJarScannerCallback objCallBack = *new* TldJarScannerCallback();
jarScanner.scan(context.getServletContext(),
context.getLoader().getClassLoader(),
objCallBack, *noTldJars*);
*if*(objCallBack.scanFoundNoTLDs()){
*log*.info(*sm*.getString("tldConfig.noTldSummary"));
}
I tested the fix and Summary message is getting added to log.
Attached the java file that contains these changes.
Please review and let me know if the fix is ok or not.
I will send another mail for pluggability scan fix details for Tomcat7.0
Thanks,
Pravallika (VIN)
On Sun, Mar 29, 2015 at 4:07 AM, Mark Thomas <ma...@apache.org> wrote:
> On 26/03/2015 13:27, Pravallika Peddi wrote:
>
> <snip/>
>
> > 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”
>
> jdom.jar isn't covered by the existing filters.
>
> <snip/>
>
> > 3) 3) So I am planning to provide a fix as below for Tomcat
> 7.0
> > TLD scan:
>
> Looks OK so far.
>
> <snip/>
>
> > 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
>
> Look again. It certainly is possible to add the summary message for TLDs
> in Tomcat 7.
>
> > 4) Tomcat7.0 ContextConfig scan is taking less time, hence I feel we can
> > ignore it for now.
>
> I disagree. The pluggability scanning can add a significant start-up
> delay to web applications. The reason that the bug report was opened in
> the first place is the time taken for the pluggability scans.
>
> > Please let me know your opinion.
>
> I think you have some more research to do.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Reg: Bug 56438
Posted by Mark Thomas <ma...@apache.org>.
On 09/04/2015 13:25, Pravallika Peddi wrote:
> Hi Mark,
>
>
>
> I can add the Boolean variable at ContextConfig class level so that all
> pluggability scans can access it and set the value accordingly.
That is too high. It needs to be per JAR.
> Almost all web-inf/lib/class scans are internally calling
> “processAnnotationsStream()” method of ContextConfig.java. So in this
> method I can change the Boolean variable to true if annotations are found.
Almost? That isn't really good enough. This has to be comprehensive to
be useful.
> Here the problem is: In case if a JAR is unnecessarily processed we can
> ask user to add that jAR under “JarsToSkip” property. But in case if a
> class file is scanned unnecessarily, we cannot ask user to add it under
> “JARsToSkip” property.
>
> So I felt there is no point in handling for class scans.
I agree for classes under WEB-INF/classes. For classes in a JAR then if
all the classes are scanned unnecessarily then the JAR is a candidate
for being skipped.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Reg: Bug 56438
Posted by Pravallika Peddi <re...@gmail.com>.
Hi Mark,
I can add the Boolean variable at ContextConfig class level so that all
pluggability scans can access it and set the value accordingly.
Almost all web-inf/lib/class scans are internally calling
“processAnnotationsStream()” method of ContextConfig.java. So in this
method I can change the Boolean variable to true if annotations are found.
Here the problem is: In case if a JAR is unnecessarily processed we can
ask user to add that jAR under “JarsToSkip” property. But in case if a
class file is scanned unnecessarily, we cannot ask user to add it under
“JARsToSkip” property.
So I felt there is no point in handling for class scans.
Please correct me if my understanding is wrong.
Thanks,
Pravallika(VIN)
On Thu, Apr 9, 2015 at 1:10 PM, Mark Thomas <ma...@apache.org> wrote:
> On 08/04/2015 14:07, Pravallika Peddi wrote:
> > Hi Mark,
> >
> > *Fix for Pluggability Scan in Tomcat 7.0: *
>
> You have only addressed fragment scanning. You have not addressed the
> other scans such as class scanning which are part of the pluggability
> scanning process.
>
> I agree adding a flag to track if a patch is found is the way to solve
> this. I disagree with where you have placed it. It needs to be somewhere
> that is accessible for all types of pluggability scans.
>
> Mark
>
> >
> >
> >
> > 1) Org.apache.catalina.startup.ContextConfig.java à
> > processJarsForWebFragments(WebXml application)
> >
> >
> >
> > FragmentJarScannerCallbackcallback =
> >
> > *new*FragmentJarScannerCallback(parseRequired);
> >
> >
> >
> > jarScanner.scan(context.getServletContext(),
> >
> > context.getLoader().getClassLoader(), callback,
> >
> > /pluggabilityJarsToSkip/);
> >
> >
> >
> > *if*(callback.scanFoundNoFragments()){
> >
> >
> /log/.info(/sm/.getString("contextConfig.NoFragmentSummary"));
> >
> > }
> >
> >
> >
> >
> >
> > 2) In Org.apache.catalina.startup.ContextConfig.java à
> > FragmentJarScannerCallbackinner class:
> >
> >
> >
> > Add new Boolean variable:
> >
> > private boolean fragmentFoundInJar = false;
> >
> >
> >
> > *Create a method to return the variable status.*
> >
> > *public**boolean*scanFoundNoFragments(){
> >
> > *return*!fragmentFoundInJar;
> >
> > }
> >
> >
> >
> > Attached the class file with fix.
> >
> >
> > Thanks,
> >
> > Pravallika(VIN)
> >
> >
> > On Sun, Mar 29, 2015 at 4:07 AM, Mark Thomas <markt@apache.org
> > <ma...@apache.org>> wrote:
> >
> > On 26/03/2015 13:27, Pravallika Peddi wrote:
> >
> > <snip/>
> >
> > > 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”
> >
> > jdom.jar isn't covered by the existing filters.
> >
> > <snip/>
> >
> > > 3) 3) So I am planning to provide a fix as below for
> Tomcat 7.0
> > > TLD scan:
> >
> > Looks OK so far.
> >
> > <snip/>
> >
> > > 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
> >
> > Look again. It certainly is possible to add the summary message for
> TLDs
> > in Tomcat 7.
> >
> > > 4) Tomcat7.0 ContextConfig scan is taking less time, hence I feel
> we can
> > > ignore it for now.
> >
> > I disagree. The pluggability scanning can add a significant start-up
> > delay to web applications. The reason that the bug report was opened
> in
> > the first place is the time taken for the pluggability scans.
> >
> > > Please let me know your opinion.
> >
> > I think you have some more research to do.
> >
> > Mark
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Reg: Bug 56438
Posted by Mark Thomas <ma...@apache.org>.
On 08/04/2015 14:07, Pravallika Peddi wrote:
> Hi Mark,
>
> *Fix for Pluggability Scan in Tomcat 7.0: *
You have only addressed fragment scanning. You have not addressed the
other scans such as class scanning which are part of the pluggability
scanning process.
I agree adding a flag to track if a patch is found is the way to solve
this. I disagree with where you have placed it. It needs to be somewhere
that is accessible for all types of pluggability scans.
Mark
>
>
>
> 1) Org.apache.catalina.startup.ContextConfig.java à
> processJarsForWebFragments(WebXml application)
>
>
>
> FragmentJarScannerCallbackcallback =
>
> *new*FragmentJarScannerCallback(parseRequired);
>
>
>
> jarScanner.scan(context.getServletContext(),
>
> context.getLoader().getClassLoader(), callback,
>
> /pluggabilityJarsToSkip/);
>
>
>
> *if*(callback.scanFoundNoFragments()){
>
> /log/.info(/sm/.getString("contextConfig.NoFragmentSummary"));
>
> }
>
>
>
>
>
> 2) In Org.apache.catalina.startup.ContextConfig.java à
> FragmentJarScannerCallbackinner class:
>
>
>
> Add new Boolean variable:
>
> private boolean fragmentFoundInJar = false;
>
>
>
> *Create a method to return the variable status.*
>
> *public**boolean*scanFoundNoFragments(){
>
> *return*!fragmentFoundInJar;
>
> }
>
>
>
> Attached the class file with fix.
>
>
> Thanks,
>
> Pravallika(VIN)
>
>
> On Sun, Mar 29, 2015 at 4:07 AM, Mark Thomas <markt@apache.org
> <ma...@apache.org>> wrote:
>
> On 26/03/2015 13:27, Pravallika Peddi wrote:
>
> <snip/>
>
> > 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”
>
> jdom.jar isn't covered by the existing filters.
>
> <snip/>
>
> > 3) 3) So I am planning to provide a fix as below for Tomcat 7.0
> > TLD scan:
>
> Looks OK so far.
>
> <snip/>
>
> > 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
>
> Look again. It certainly is possible to add the summary message for TLDs
> in Tomcat 7.
>
> > 4) Tomcat7.0 ContextConfig scan is taking less time, hence I feel we can
> > ignore it for now.
>
> I disagree. The pluggability scanning can add a significant start-up
> delay to web applications. The reason that the bug report was opened in
> the first place is the time taken for the pluggability scans.
>
> > Please let me know your opinion.
>
> I think you have some more research to do.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Reg: Bug 56438
Posted by Pravallika Peddi <re...@gmail.com>.
Hi Mark,
*Fix for Pluggability Scan in Tomcat 7.0: *
1) Org.apache.catalina.startup.ContextConfig.java à
processJarsForWebFragments(WebXml
application)
FragmentJarScannerCallback callback =
*new* FragmentJarScannerCallback(parseRequired);
jarScanner.scan(context.getServletContext(),
context.getLoader().getClassLoader(), callback,
*pluggabilityJarsToSkip*);
*if*(callback.scanFoundNoFragments()){
*log*.info(*sm*.getString("contextConfig.NoFragmentSummary"));
}
2) In Org.apache.catalina.startup.ContextConfig.java à
FragmentJarScannerCallback inner class:
Add new Boolean variable:
private boolean fragmentFoundInJar = false;
*Create a method to return the variable status.*
*public* *boolean* scanFoundNoFragments(){
*return* !fragmentFoundInJar;
}
Attached the class file with fix.
Thanks,
Pravallika(VIN)
On Sun, Mar 29, 2015 at 4:07 AM, Mark Thomas <ma...@apache.org> wrote:
> On 26/03/2015 13:27, Pravallika Peddi wrote:
>
> <snip/>
>
> > 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”
>
> jdom.jar isn't covered by the existing filters.
>
> <snip/>
>
> > 3) 3) So I am planning to provide a fix as below for Tomcat
> 7.0
> > TLD scan:
>
> Looks OK so far.
>
> <snip/>
>
> > 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
>
> Look again. It certainly is possible to add the summary message for TLDs
> in Tomcat 7.
>
> > 4) Tomcat7.0 ContextConfig scan is taking less time, hence I feel we can
> > ignore it for now.
>
> I disagree. The pluggability scanning can add a significant start-up
> delay to web applications. The reason that the bug report was opened in
> the first place is the time taken for the pluggability scans.
>
> > Please let me know your opinion.
>
> I think you have some more research to do.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Reg: Bug 56438
Posted by Pravallika Peddi <re...@gmail.com>.
Hi Mark,
Currently there is no mechanism to skip the JARs from Pluggability scan in
Tomcat 8.0.
Below are the fix details that i propose for *tomcat 8* pluggability scan
problem:
1) Added below code in
org.apache.tomcat.util.descriptor.web.FragmentJarScannerCallBack.java à
private boolean fragmentFoundInJar = false;
In scan methods of this calls setting this variable to true when
needed and if JAR does not has any fragments added a message:
*if(!fragmentFoundInJar){*
* log.info
<http://log.info>(Localizer.getMessage("jspc.warning.NoFragmentInFile",
fragmentFile.getAbsolutePath()));*
* }*
Added below method to retrieve this value:
*public* *boolean* scanFoundNoFragments(){
*return* !fragmentFoundInJar;
}
2) We are doing fragment scan in two locations:
*First:*
Org.apache.catalina.startup.ContextConfig.java à
processJarsForWebFragments(WebXml
application)
Highlighted text is the Fix:
FragmentJarScannerCallback callback =
*new* FragmentJarScannerCallback(webXmlParser, delegate,
parseRequired);
jarScanner.scan(JarScanType.*PLUGGABILITY*,
context.getServletContext(), callback);
*boolean* scanFoundNoFrag = callback.scanFoundNoFragments();
*if*(!callback.scanFoundNoFragments()){
*log*.info(Localizer.*getMessage*(
"jspc.warning.NoFragmentSummary"));
}
*if* (!callback.isOk()) {
ok = *false*;
}
* Second:*
Org.apache.jasper.servlet.JspCServletContext.java à
scanForFragments(WebXmlParser
webXmlParser)
Highlighted text is the fix:
FragmentJarScannerCallback callback =
*new* FragmentJarScannerCallback(webXmlParser, *false*,
*true*);
scanner.scan(JarScanType.*PLUGGABILITY*, *this*, callback);
*if*(!callback.scanFoundNoFragments()){
log(Localizer.*getMessage*("jspc.warning.NoFragmentSummary"));
}
*if* (!callback.isOk()) {
*throw* *new* JasperException(Localizer.*getMessage*(
"jspc.error.invalidFragment"));
}
I tested the changes and the Jars mentioned under
"tomcat.util.scan.StandardJarScanFilter.jarsToSkip"
are getting skipped from both pluggability and tld scans.
Attached the changed classes for review.
For *Tomcat7* related changes, i will send another email.
On Sun, Mar 29, 2015 at 4:07 AM, Mark Thomas <ma...@apache.org> wrote:
> On 26/03/2015 13:27, Pravallika Peddi wrote:
>
> <snip/>
>
> > 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”
>
> jdom.jar isn't covered by the existing filters.
>
> <snip/>
>
> > 3) 3) So I am planning to provide a fix as below for Tomcat
> 7.0
> > TLD scan:
>
> Looks OK so far.
>
> <snip/>
>
> > 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
>
> Look again. It certainly is possible to add the summary message for TLDs
> in Tomcat 7.
>
> > 4) Tomcat7.0 ContextConfig scan is taking less time, hence I feel we can
> > ignore it for now.
>
> I disagree. The pluggability scanning can add a significant start-up
> delay to web applications. The reason that the bug report was opened in
> the first place is the time taken for the pluggability scans.
>
> > Please let me know your opinion.
>
> I think you have some more research to do.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Reg: Bug 56438
Posted by Mark Thomas <ma...@apache.org>.
On 26/03/2015 13:27, Pravallika Peddi wrote:
<snip/>
> 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”
jdom.jar isn't covered by the existing filters.
<snip/>
> 3) 3) So I am planning to provide a fix as below for Tomcat 7.0
> TLD scan:
Looks OK so far.
<snip/>
> 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
Look again. It certainly is possible to add the summary message for TLDs
in Tomcat 7.
> 4) Tomcat7.0 ContextConfig scan is taking less time, hence I feel we can
> ignore it for now.
I disagree. The pluggability scanning can add a significant start-up
delay to web applications. The reason that the bug report was opened in
the first place is the time taken for the pluggability scans.
> Please let me know your opinion.
I think you have some more research to do.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Reg: Bug 56438
Posted by Pravallika Peddi <re...@gmail.com>.
Hi Mark,
can you please review my previous mail and confirm whether i can proceed
with the fix or not?
Thanks,
Pravallika(VIN)
On Thu, Mar 26, 2015 at 6:57 PM, Pravallika Peddi <re...@gmail.com>
wrote:
> 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.valli@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.valli@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-unsubscribe@tomcat.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
>> >>>
>> >>>
>> >>
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>