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
>
>
