Re: Problem with JarScanFilter, maybe a bug?
On Mon, Jul 6, 2020 at 5:05 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Vitor,
>
> On 7/6/20 15:50, Vitor Medina Cruz wrote:
> > On Mon, Jul 6, 2020 at 8:57 AM Mark Thomas
> > wrote:
> >
> >> On 06/07/2020 12:25, Mark Thomas wrote:
> >>> On 03/07/2020 13:40, Vitor Medina Cruz wrote:
> >>>> On Thu, Jul 2, 2020 at 11:21 AM Mark Thomas
> >>>> wrote:
> >>>>
> >>>>> On 02/07/2020 14:14, Vitor Medina Cruz wrote:
> >>>>>> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas
> >>>>>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> @WebFiler, @WebListener and @WebServlet are deployment
> >>>>>>> annotations so scanning for these is controlled by the
> >>>>>>> JarScanner.
> >>>>>>>
> >>>>>>> If an SCI has an @HandlesTypes annotation then all JARs
> >>>>>>> that are potential SCI sources will be scanned for
> >>>>>>> matches. To put it another way, the JarScanner
> >>>>>>> configuration does NOT control the search for
> >>>>>>> @HandlesTypes matches. Any JAR eligible to provide an
> >>>>>>> SCI will be scanned for @HandlesTypes. Those JARs are
> >>>>>>> controlled by
> >>>>>
> >>>>>>>
> >>>>>>
> >>>>>> Ok, and if a jar doesn't provide a web-fragment name? In
> >>>>>> this old
> >> post(
> >>>>>>
> >>>>>
> >> http://tomcat.10.x6.nabble.com/Why-does-absolute-ordering-in-web-xml-
> without-others-kill-classpath-scanning-td5029985.html
> <http://tomcat.10.x6.nabble.com/Why-does-absolute-ordering-in-web-xml-without-others-kill-classpath-scanning-td5029985.html>
> >>>>>
> >>
> )
> >>>>>> it is said :
> >>>>>>
> >>>>>> "Tomcat will give these a name equal to the name of the
> >>>>>> JAR file so
> >> you
> >>>>> can
> >>>>>> use it in ordering. That is a Tomcat specific feature."
> >>>>>>
> >>>>>> This is/holds true? I tried with no success
> >>>>>
> >>>>> It should do. So for foobar-0.3.jar the name should be
> >>>>> "foobar-0.3.jar"
> >>>>>
> >>>>>
> >>>> Don't work... :( both in Tomcat 8.5.56 and 9.0.36 I got a
> >>>> "Used a wrong fragment name [flow-server-2.2.1.jar] at
> >>>> web.xml absolute-ordering tag"
> >>>
> >>> Hmm. Let me look into what is going on here...
> >>
> >> My memory and the comment from 2015 were incorrect. It is the
> >> full URL that is used rather than just the name.
> >>
> >> While the JAR name should be unique within WEB-INF/lib, the JAR
> >> scanning extends outside of that to include CATALINA_BASE/lib and
> >> potentially the the bootstrap class path. Duplicates can trigger
> >> deployment failure - hence the more cautious approach.
> >>
> >> As an example, this is the URL on my system (taken from Tomcat
> >> 10.0.x but the code should be the same in 9.0.x and 8.5.x):
> >>
> >>
> >> file:/home/mark/repos/asf-tomcat-10.0.x/output/build/webapps/examples
> /WEB-INF/lib/taglibs-standard-impl-1.2.5-migrated-0.0.1.jar
> >>
> >>
> >>
> Rather long for a fragment but it ensures uniqueness.
> >>
> >
> > Thanks, that worked! In my windows machine I used file:/C:/ > the path>
> >
> >
> > Is it possible to use relative path of some sort in order to not
> > tie this config to my machine?
>
> No promises, but you could try:
>
> ${catalina.base}/path/relative/to/tomcat
>
> for example:
>
> ${catalina.base}/webapps/mywebapp/WEB-INF/lib/taglibs-standard-impl-1.2.
> 5-migrated-0.0.1.jar
>
> I don't know if the system-property-replacement will be honored in
> that particular context, but it is supported in others. It seems like
> that could be added if it's not already supported.
>
Thanks, but that won't do, differences between dev-debug env and production
don't make that practical. If I could start from the webapp deployed folder
would be better, like this:
${deploy.foler}/WEB-INF/lib/taglibs-standard-impl-1.2
But I will take that isn't possible. :(
regards,
Vitor
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8Dg/MACgkQHPApP6U8
> pFh04RAApg2rrmhJmLnupkKTHLAPL/yud4WPpYiVRJaNXoX32Bp3FfHIPH+2nMGL
> l00gVVsPxmN1jMaOrhpgQsNT033QiUuHm9LaZjXBe2Md7iUAW+dhn7f0tYfA2Eds
> SpnNxMHHTEH/zsMD3WX771xqPh1qDRwW2h89NshkYTYkWaeL2UtshXRaffMipkwm
> mdRtj25wVch2rgILjup3qCyoQwgmq/9XZWsyiGVdL3YBkvijTwb79BLX00vT20vJ
> u3wWqA4zzuz1IovyKTIqSd9fGcAwCAyx+53aQgqo7nZYXtRfweZSjyx1QSWLFVdU
> u2zzkaZeoQJs47Lvu6Db4pSPFa//zitSoIhxrnXfv7xDsUPZiYQg+HG8KqXuFeAd
> x3fju5EpRDfU1snbCgAU3XZjUQpcd+9TzoTfJM8RfgkUl7AL07POrPGWWqOuYahs
> XlC7Lbf/TqGseaWZ1aVAS0JPtm/h9DzIn8K2BK4157y7hOvhhSKgiG45iNgeKt0t
> s0+i2nG0lGM9ajG34JWIkpx6vrOn1J+p0wX56ZqHGu4DmznMqg5HlN32N1p/FdgX
> AJk5qxfbpayNwJGornvDRduXmQwT8NhKOillebU5DfAiWYMaYlu1UAQ643cx06/h
> 44U/o8mJDCsSYWJkgZIKq/0OkAtUmkCGYnIGTmRW4fXptpyENM4=
> =Vczr
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Re: Problem with JarScanFilter, maybe a bug?
On Mon, Jul 6, 2020 at 8:57 AM Mark Thomas wrote: > On 06/07/2020 12:25, Mark Thomas wrote: > > On 03/07/2020 13:40, Vitor Medina Cruz wrote: > >> On Thu, Jul 2, 2020 at 11:21 AM Mark Thomas wrote: > >> > >>> On 02/07/2020 14:14, Vitor Medina Cruz wrote: > >>>> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas wrote: > >>> > >>> > >>> > >>>>> @WebFiler, @WebListener and @WebServlet are deployment annotations so > >>>>> scanning for these is controlled by the JarScanner. > >>>>> > >>>>> If an SCI has an @HandlesTypes annotation then all JARs that are > >>>>> potential SCI sources will be scanned for matches. To put it another > >>>>> way, the JarScanner configuration does NOT control the search for > >>>>> @HandlesTypes matches. Any JAR eligible to provide an SCI will be > >>>>> scanned for @HandlesTypes. Those JARs are controlled by > >>> > >>>>> > >>>> > >>>> Ok, and if a jar doesn't provide a web-fragment name? In this old > post( > >>>> > >>> > http://tomcat.10.x6.nabble.com/Why-does-absolute-ordering-in-web-xml-without-others-kill-classpath-scanning-td5029985.html > >>> ) > >>>> it is said : > >>>> > >>>> "Tomcat will give these a name equal to the name of the JAR file so > you > >>> can > >>>> use it in ordering. That is a Tomcat specific feature." > >>>> > >>>> This is/holds true? I tried with no success > >>> > >>> It should do. So for foobar-0.3.jar the name should be "foobar-0.3.jar" > >>> > >>> > >> Don't work... :( both in Tomcat 8.5.56 and 9.0.36 I got a "Used a wrong > >> fragment name [flow-server-2.2.1.jar] at web.xml absolute-ordering tag" > > > > Hmm. Let me look into what is going on here... > > My memory and the comment from 2015 were incorrect. It is the full URL > that is used rather than just the name. > > While the JAR name should be unique within WEB-INF/lib, the JAR scanning > extends outside of that to include CATALINA_BASE/lib and potentially the > the bootstrap class path. Duplicates can trigger deployment failure - > hence the more cautious approach. > > As an example, this is the URL on my system (taken from Tomcat 10.0.x > but the code should be the same in 9.0.x and 8.5.x): > > > file:/home/mark/repos/asf-tomcat-10.0.x/output/build/webapps/examples/WEB-INF/lib/taglibs-standard-impl-1.2.5-migrated-0.0.1.jar > > Rather long for a fragment but it ensures uniqueness. > Thanks, that worked! In my windows machine I used file:/C:/ Is it possible to use relative path of some sort in order to not tie this config to my machine? > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Problem with JarScanFilter, maybe a bug?
On Thu, Jul 2, 2020 at 11:21 AM Mark Thomas wrote: > On 02/07/2020 14:14, Vitor Medina Cruz wrote: > > On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas wrote: > > > > >> @WebFiler, @WebListener and @WebServlet are deployment annotations so > >> scanning for these is controlled by the JarScanner. > >> > >> If an SCI has an @HandlesTypes annotation then all JARs that are > >> potential SCI sources will be scanned for matches. To put it another > >> way, the JarScanner configuration does NOT control the search for > >> @HandlesTypes matches. Any JAR eligible to provide an SCI will be > >> scanned for @HandlesTypes. Those JARs are controlled by > > >> > > > > Ok, and if a jar doesn't provide a web-fragment name? In this old post( > > > http://tomcat.10.x6.nabble.com/Why-does-absolute-ordering-in-web-xml-without-others-kill-classpath-scanning-td5029985.html > ) > > it is said : > > > > "Tomcat will give these a name equal to the name of the JAR file so you > can > > use it in ordering. That is a Tomcat specific feature." > > > > This is/holds true? I tried with no success > > It should do. So for foobar-0.3.jar the name should be "foobar-0.3.jar" > > Don't work... :( both in Tomcat 8.5.56 and 9.0.36 I got a "Used a wrong fragment name [flow-server-2.2.1.jar] at web.xml absolute-ordering tag" Maybe it is easy to turn off all scanning and figure out a way to configure everything explicitly... regards, Vitor > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Problem with JarScanFilter, maybe a bug?
On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas wrote: > On 01/07/2020 20:28, Vitor Medina Cruz wrote: > > On Wed, Jul 1, 2020 at 3:19 PM Mark Thomas wrote: > > > >> On 01/07/2020 18:09, Vitor Medina Cruz wrote: > >>> On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas wrote: > >>> > >>>> On 30/06/2020 14:19, Vitor Medina Cruz wrote: > >>>>> Hello, > >>>>> > >>>>> I am trying to configure Tomcat in a way that it makes SCI scan only > in > >>>>> jars I explicitly specify to. I followed instructions from > >>>>> https://tomcat.apache.org/tomcat-8.5-doc/config/jar-scan-filter.htm, > >> in > >>>>> both Tomcat 8 and 9, but with no success. I posted a question on > >>>>> stackoverflow that explains more in detail what I did: > >>>>> > >>>> > >> > https://stackoverflow.com/questions/62602550/how-to-specify-which-classes-and-jars-gets-scanned-for-servlet-annotations-in-to > >>>>> > >>>>> And I also found other unanswered questions pointing to the same > >> problem, > >>>>> here is one example: > >>>>> > >>>> > >> > https://stackoverflow.com/questions/52876216/tomcat-too-slow-scanning-for-annotations > >>>>> . > >>>>> > >>>>> The thing is that it is looking like an error to me because logs > tells > >>>> that > >>>>> scanning is done as configured — if I add a jar for scanning in > >>>>> JarScanFilter, the log show it is scanned, if I remove it, the log > stop > >>>>> reporting it's scanning — but after that, no matter what > configuration > >> I > >>>>> made with JarScanFilter, the WebappServiceLoader loads servlet > >> annotated > >>>>> classes, such as @WebListener. > >>>> > >>>> The JarScanner machinery handles annotation and TLD scanning. > >>>> > >>>> WebappServiceLoader handles SCIs which are handled under the standard > >>>> service loader mechanism. SCIs can load classes. > >>>> > >>>>> Any leads? Ideas? Anyone can confirm if that is an error or if I am > >> using > >>>>> the functionality wrongly or if I understand it wrongly. > >>>> > >>>> It looks like you aren't preventing the SCIs from being loaded. > >>>> > >>>> The specification isn't as clear as it could be here and there are > still > >>>> a few gaps. That is being worked on at Eclipse. A useful summary of > the > >>>> current position can be found at: > >>>> > >>>> > >>>> > >> > https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/catalina/startup/ContextConfig.java#L1092 > >>>> > >>>> The simplest way to block the Servlet 3 pluggability features is: > >>>> > >>>> 1. Add metadata-complete="true" to the web-app element in web.xml > >>>>(disables annotation scanning for deploy time annotations - > >>>> Servlet 3.1, 8.1) > >>>> > >>>> 2. Add to web.xml > >>>>(disables any SCIs - Servlet 3.1, 8.2.2.d) > >>>> > >>>> Mark > >>>> > >>>> > >>> Thanks. I, however, don't want to block all Servlet 3 pluggability as > >> there > >>> are frameworks already being made with no way of configuring it other > >> than > >>> that > >> > >> You can always explicitly define configuration in web.xml. > >> > >>> I would like to selectively choose which jars to be scanned in > >>> order to avoid performance issues and rogue classes to be loaded. As is > >>> seems, nor Servlet specification nor Tomcat in specific provides a way > of > >>> doing that, is that correct? > >> > >> No. > >> > >> Scanning != SCI loading. > >> > >> Scanning for deployment annotations can be controlled by the JarScanner. > >> > >> SCI loading can be controlled by an element that > >> includes the JARs from which you do want to load SCIs. > >> > >> > > But how can SCI loading takes place without scanning? That was what I > > thought when I tried to control SCI loads, if I didn't scan any class at > > all then no
Re: Problem with JarScanFilter, maybe a bug?
On Wed, Jul 1, 2020 at 3:19 PM Mark Thomas wrote: > On 01/07/2020 18:09, Vitor Medina Cruz wrote: > > On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas wrote: > > > >> On 30/06/2020 14:19, Vitor Medina Cruz wrote: > >>> Hello, > >>> > >>> I am trying to configure Tomcat in a way that it makes SCI scan only in > >>> jars I explicitly specify to. I followed instructions from > >>> https://tomcat.apache.org/tomcat-8.5-doc/config/jar-scan-filter.htm, > in > >>> both Tomcat 8 and 9, but with no success. I posted a question on > >>> stackoverflow that explains more in detail what I did: > >>> > >> > https://stackoverflow.com/questions/62602550/how-to-specify-which-classes-and-jars-gets-scanned-for-servlet-annotations-in-to > >>> > >>> And I also found other unanswered questions pointing to the same > problem, > >>> here is one example: > >>> > >> > https://stackoverflow.com/questions/52876216/tomcat-too-slow-scanning-for-annotations > >>> . > >>> > >>> The thing is that it is looking like an error to me because logs tells > >> that > >>> scanning is done as configured — if I add a jar for scanning in > >>> JarScanFilter, the log show it is scanned, if I remove it, the log stop > >>> reporting it's scanning — but after that, no matter what configuration > I > >>> made with JarScanFilter, the WebappServiceLoader loads servlet > annotated > >>> classes, such as @WebListener. > >> > >> The JarScanner machinery handles annotation and TLD scanning. > >> > >> WebappServiceLoader handles SCIs which are handled under the standard > >> service loader mechanism. SCIs can load classes. > >> > >>> Any leads? Ideas? Anyone can confirm if that is an error or if I am > using > >>> the functionality wrongly or if I understand it wrongly. > >> > >> It looks like you aren't preventing the SCIs from being loaded. > >> > >> The specification isn't as clear as it could be here and there are still > >> a few gaps. That is being worked on at Eclipse. A useful summary of the > >> current position can be found at: > >> > >> > >> > https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/catalina/startup/ContextConfig.java#L1092 > >> > >> The simplest way to block the Servlet 3 pluggability features is: > >> > >> 1. Add metadata-complete="true" to the web-app element in web.xml > >>(disables annotation scanning for deploy time annotations - > >> Servlet 3.1, 8.1) > >> > >> 2. Add to web.xml > >>(disables any SCIs - Servlet 3.1, 8.2.2.d) > >> > >> Mark > >> > >> > > Thanks. I, however, don't want to block all Servlet 3 pluggability as > there > > are frameworks already being made with no way of configuring it other > than > > that > > You can always explicitly define configuration in web.xml. > > > I would like to selectively choose which jars to be scanned in > > order to avoid performance issues and rogue classes to be loaded. As is > > seems, nor Servlet specification nor Tomcat in specific provides a way of > > doing that, is that correct? > > No. > > Scanning != SCI loading. > > Scanning for deployment annotations can be controlled by the JarScanner. > > SCI loading can be controlled by an element that > includes the JARs from which you do want to load SCIs. > > But how can SCI loading takes place without scanning? That was what I thought when I tried to control SCI loads, if I didn't scan any class at all then no SCI should be loaded since no annotations will be found, but that is not the case, so SCI loading must be doing an independent scanning on it's own. In any way, leaving behind internal machinery, is it possible to define in Tomcat which jars should be considered for annotation processing and SCI loading, and which not? I wanna tell Tomcat to only look and load for @WebFiler, @WebListener, @WebServlet, @HandlesTypes and etc on specific jars. Is that possible? Regards, Vitor > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Problem with JarScanFilter, maybe a bug?
On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas wrote: > On 30/06/2020 14:19, Vitor Medina Cruz wrote: > > Hello, > > > > I am trying to configure Tomcat in a way that it makes SCI scan only in > > jars I explicitly specify to. I followed instructions from > > https://tomcat.apache.org/tomcat-8.5-doc/config/jar-scan-filter.htm, in > > both Tomcat 8 and 9, but with no success. I posted a question on > > stackoverflow that explains more in detail what I did: > > > https://stackoverflow.com/questions/62602550/how-to-specify-which-classes-and-jars-gets-scanned-for-servlet-annotations-in-to > > > > And I also found other unanswered questions pointing to the same problem, > > here is one example: > > > https://stackoverflow.com/questions/52876216/tomcat-too-slow-scanning-for-annotations > > . > > > > The thing is that it is looking like an error to me because logs tells > that > > scanning is done as configured — if I add a jar for scanning in > > JarScanFilter, the log show it is scanned, if I remove it, the log stop > > reporting it's scanning — but after that, no matter what configuration I > > made with JarScanFilter, the WebappServiceLoader loads servlet annotated > > classes, such as @WebListener. > > The JarScanner machinery handles annotation and TLD scanning. > > WebappServiceLoader handles SCIs which are handled under the standard > service loader mechanism. SCIs can load classes. > > > Any leads? Ideas? Anyone can confirm if that is an error or if I am using > > the functionality wrongly or if I understand it wrongly. > > It looks like you aren't preventing the SCIs from being loaded. > > The specification isn't as clear as it could be here and there are still > a few gaps. That is being worked on at Eclipse. A useful summary of the > current position can be found at: > > > https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/catalina/startup/ContextConfig.java#L1092 > > The simplest way to block the Servlet 3 pluggability features is: > > 1. Add metadata-complete="true" to the web-app element in web.xml >(disables annotation scanning for deploy time annotations - > Servlet 3.1, 8.1) > > 2. Add to web.xml >(disables any SCIs - Servlet 3.1, 8.2.2.d) > > Mark > > Thanks. I, however, don't want to block all Servlet 3 pluggability as there are frameworks already being made with no way of configuring it other than that I would like to selectively choose which jars to be scanned in order to avoid performance issues and rogue classes to be loaded. As is seems, nor Servlet specification nor Tomcat in specific provides a way of doing that, is that correct? > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Problem with JarScanFilter, maybe a bug?
Hello, I am trying to configure Tomcat in a way that it makes SCI scan only in jars I explicitly specify to. I followed instructions from https://tomcat.apache.org/tomcat-8.5-doc/config/jar-scan-filter.htm, in both Tomcat 8 and 9, but with no success. I posted a question on stackoverflow that explains more in detail what I did: https://stackoverflow.com/questions/62602550/how-to-specify-which-classes-and-jars-gets-scanned-for-servlet-annotations-in-to And I also found other unanswered questions pointing to the same problem, here is one example: https://stackoverflow.com/questions/52876216/tomcat-too-slow-scanning-for-annotations . The thing is that it is looking like an error to me because logs tells that scanning is done as configured — if I add a jar for scanning in JarScanFilter, the log show it is scanned, if I remove it, the log stop reporting it's scanning — but after that, no matter what configuration I made with JarScanFilter, the WebappServiceLoader loads servlet annotated classes, such as @WebListener. Any leads? Ideas? Anyone can confirm if that is an error or if I am using the functionality wrongly or if I understand it wrongly. Regards, Vitor
