tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: Jar scanning, SCI scanning, fragment scanning
Date Fri, 14 Jun 2013 08:28:00 GMT
SCIs are too webapp linked to be usable by others, that's the point so it
needs to be proprietary ATM + SCI doesn't scan eveything (thinking to cdi
you cannot guess a bean is a cdi one before having analyzed it).

*Romain Manni-Bucau*
*Twitter: @rmannibucau <>*
*Blog: ***<>
*LinkedIn: ***

2013/6/14 Mark Thomas <>

> On 14/06/2013 09:14, Romain Manni-Bucau wrote:
>> well i think it will be handled for next spec as it was for interceptors
>> (but it is not that important for initializer in *applications*).
>> I don't get what's the issue using a scanner registry with "get or create"
>> semantic. Is it only tomcat doesn't need it by itself? If so my point is
>> today tomcat is almost nothing without libs and most of libs scan so IMO
>> it
>> would be a nice have to get it (even if not mandatory).
> The issue is that you are advocating a solution (a "scanner registry"
> although you have not defined what one of those is) without describing a
> problem.
> Both container and application components that need to scan JARs for
> classes and/or annotations can use an SCI which will result in a single
> scan being performed.
> You have yet to articulate a requirement that cannot be met with an SCI.
> If the problem you are trying to solve is that lots of libraries perform
> scans then I see no point in implementing a proprietary solution (a
> "scanner registry") when there is a standard solution (SCIs) available.
> Libraries are going to have to change their code for either solution so
> using the specification defined standard solution rather than a single
> proprietary solution used by only one container is clearly the way to go.
> Mark
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.**org<>
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message