You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2020/07/01 10:46:21 UTC
Re: Problem with JarScanFilter, maybe a bug?
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 <absolute-ordering></absolute-ordering> to web.xml
(disables any SCIs - Servlet 3.1, 8.2.2.d)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with JarScanFilter, maybe a bug?
Posted by Vitor Medina Cruz <vi...@gmail.com>.
On Mon, Jul 6, 2020 at 5:05 PM Christopher Schultz <
chris@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 <ma...@apache.org>
> > 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
> >>>> <ma...@apache.org> wrote:
> >>>>
> >>>>> On 02/07/2020 14:14, Vitor Medina Cruz wrote:
> >>>>>> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas
> >>>>>> <ma...@apache.org> wrote:
> >>>>>
> >>>>> <snip/>
> >>>>>
> >>>>>>> @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
> >>>>> <absolute-ordering>
> >>>>>>>
> >>>>>>
> >>>>>> 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:/<rest of
> > 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Problem with JarScanFilter, maybe a bug?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <ma...@apache.org>
> 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
>>>> <ma...@apache.org> wrote:
>>>>
>>>>> On 02/07/2020 14:14, Vitor Medina Cruz wrote:
>>>>>> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas
>>>>>> <ma...@apache.org> wrote:
>>>>>
>>>>> <snip/>
>>>>>
>>>>>>> @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
>>>>> <absolute-ordering>
>>>>>>>
>>>>>>
>>>>>> 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:/<rest of
> 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.
- -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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with JarScanFilter, maybe a bug?
Posted by Vitor Medina Cruz <vi...@gmail.com>.
On Mon, Jul 6, 2020 at 8:57 AM Mark Thomas <ma...@apache.org> 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 <ma...@apache.org> wrote:
> >>
> >>> On 02/07/2020 14:14, Vitor Medina Cruz wrote:
> >>>> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:
> >>>
> >>> <snip/>
> >>>
> >>>>> @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
> >>> <absolute-ordering>
> >>>>>
> >>>>
> >>>> 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:/<rest of the
path>
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Problem with JarScanFilter, maybe a bug?
Posted by Mark Thomas <ma...@apache.org>.
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 <ma...@apache.org> wrote:
>>
>>> On 02/07/2020 14:14, Vitor Medina Cruz wrote:
>>>> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:
>>>
>>> <snip/>
>>>
>>>>> @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
>>> <absolute-ordering>
>>>>>
>>>>
>>>> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with JarScanFilter, maybe a bug?
Posted by Mark Thomas <ma...@apache.org>.
On 03/07/2020 13:40, Vitor Medina Cruz wrote:
> On Thu, Jul 2, 2020 at 11:21 AM Mark Thomas <ma...@apache.org> wrote:
>
>> On 02/07/2020 14:14, Vitor Medina Cruz wrote:
>>> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:
>>
>> <snip/>
>>
>>>> @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
>> <absolute-ordering>
>>>>
>>>
>>> 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...
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with JarScanFilter, maybe a bug?
Posted by Vitor Medina Cruz <vi...@gmail.com>.
On Thu, Jul 2, 2020 at 11:21 AM Mark Thomas <ma...@apache.org> wrote:
> On 02/07/2020 14:14, Vitor Medina Cruz wrote:
> > On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:
>
> <snip/>
>
> >> @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
> <absolute-ordering>
> >>
> >
> > 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Problem with JarScanFilter, maybe a bug?
Posted by Mark Thomas <ma...@apache.org>.
On 02/07/2020 14:14, Vitor Medina Cruz wrote:
> On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:
<snip/>
>> @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 <absolute-ordering>
>>
>
> 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"
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with JarScanFilter, maybe a bug?
Posted by Vitor Medina Cruz <vi...@gmail.com>.
On Wed, Jul 1, 2020 at 6:48 PM Mark Thomas <ma...@apache.org> wrote:
> On 01/07/2020 20:28, Vitor Medina Cruz wrote:
> > On Wed, Jul 1, 2020 at 3:19 PM Mark Thomas <ma...@apache.org> wrote:
> >
> >> On 01/07/2020 18:09, Vitor Medina Cruz wrote:
> >>> On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas <ma...@apache.org> 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 <absolute-ordering></absolute-ordering> 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 <absolute-ordering> 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.
>
> No.
>
> SCIs are discovered via the service loader mechanism.
>
> Deployment annotations are discovered via JAR scanning.
>
> These are completely separate mechanisms.
>
> Note that an SCI may load and configure Servlets, Filters, Listeners etc.
>
>
Humm, ok, thanks, I understand now.
> > 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?
>
> Yes.
>
> JarScanner for deployment annotations.
>
> <absolute-ordering> for SCIs and @HandlesTypes matches.
>
> > I wanna tell Tomcat to only look and load for
> > @WebFiler, @WebListener, @WebServlet, @HandlesTypes and etc on specific
> > jars. Is that possible?
>
> @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 <absolute-ordering>
>
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
Thanks,
Vitor
>
> Mark
>
Re: Problem with JarScanFilter, maybe a bug?
Posted by Mark Thomas <ma...@apache.org>.
On 01/07/2020 20:28, Vitor Medina Cruz wrote:
> On Wed, Jul 1, 2020 at 3:19 PM Mark Thomas <ma...@apache.org> wrote:
>
>> On 01/07/2020 18:09, Vitor Medina Cruz wrote:
>>> On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas <ma...@apache.org> 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 <absolute-ordering></absolute-ordering> 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 <absolute-ordering> 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.
No.
SCIs are discovered via the service loader mechanism.
Deployment annotations are discovered via JAR scanning.
These are completely separate mechanisms.
Note that an SCI may load and configure Servlets, Filters, Listeners etc.
> 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?
Yes.
JarScanner for deployment annotations.
<absolute-ordering> for SCIs and @HandlesTypes matches.
> I wanna tell Tomcat to only look and load for
> @WebFiler, @WebListener, @WebServlet, @HandlesTypes and etc on specific
> jars. Is that possible?
@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 <absolute-ordering>
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with JarScanFilter, maybe a bug?
Posted by Vitor Medina Cruz <vi...@gmail.com>.
On Wed, Jul 1, 2020 at 3:19 PM Mark Thomas <ma...@apache.org> wrote:
> On 01/07/2020 18:09, Vitor Medina Cruz wrote:
> > On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas <ma...@apache.org> 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 <absolute-ordering></absolute-ordering> 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 <absolute-ordering> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Problem with JarScanFilter, maybe a bug?
Posted by Mark Thomas <ma...@apache.org>.
On 01/07/2020 18:09, Vitor Medina Cruz wrote:
> On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas <ma...@apache.org> 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 <absolute-ordering></absolute-ordering> 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 <absolute-ordering> element that
includes the JARs from which you do want to load SCIs.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problem with JarScanFilter, maybe a bug?
Posted by Vitor Medina Cruz <vi...@gmail.com>.
On Wed, Jul 1, 2020 at 7:46 AM Mark Thomas <ma...@apache.org> 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 <absolute-ordering></absolute-ordering> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>