Re: Reg: Bug 56438
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 ma...@apache.org
mailto: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-unsubscr...@tomcat.apache.org
mailto:dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
mailto: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
Re: Reg: Bug 56438
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 ma...@apache.org
mailto: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-unsubscr...@tomcat.apache.org
mailto:dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
mailto: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
Re: Reg: Bug 56438
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 ma...@apache.org
mailto: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-unsubscr...@tomcat.apache.org
mailto:dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
mailto: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
Re: Reg: Bug 56438
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Reg: Bug 56438
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-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
Re: Reg: Bug 56438
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-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
Re: Reg: Bug 56438
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-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
Re: Reg: Bug 56438
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 reachme.va...@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'.
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.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
Re: Reg: Bug 56438
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
Re: Reg: Bug 56438
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. 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) 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. 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
Re: Reg: Bug 56438
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
Re: Reg: Bug 56438
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
Re: Reg: Bug 56438
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. Enhancement requested is: If some jar file is missing then add a log message in log file saying add it under JarsToSkip. Please correct me if my understanding about the bug is wrong. 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
Re: Reg: Bug 56438
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
Re: Reg: Bug 56438
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
