tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
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 <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/6/14 Mark Thomas <markt@apache.org>

> 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<dev-unsubscribe@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

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