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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to