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