can work this way, today that's not as easy as it could to replace tomat scanning(s) (tld, classes) by tomee one.
About CDI: you basically need to pass all classes on jars with a beans.xml to the CDI container so @HandlesType doesn't match this need really well. *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:28, Romain Manni-Bucau wrote: > >> SCIs are too webapp linked to be usable by others, that's the point >> > > so it needs to be proprietary ATM > > If the problem you are trying to solve is JAR scanning outside of the > Servlet container then that - frankly - isn't a Tomcat problem. Tomcat is > concerned about scanning for classes and annotations within a web > application and the standard API for that is an SCI. > > SCIs are just an interface so if a broader scanning solution was available > (either in Java EE or Java SE) then that broader solution could be taken > advantage of either directly in Tomcat or by whatever product was embedding > Tomcat. > > If TomEE has a broader solution and it could be easier to plug the results > of that into Tomcat so make them available through the SCI interface then > present some concrete proposals on changes to make the scanning more > pluggable and they'll be considered. > > > + SCI doesn't scan eveything (thinking to cdi >> you cannot guess a bean is a cdi one before having analyzed it). >> > > SCIs don't scan anything. SCIs are merely the interface through which > clients declare their interests and the servlet container passes back the > results. It is certainly the case that every class has to be scanned if a > @HandlesType is present on any SCI. > > If you are saying that CDI implementations need information that isn't > available though the SCI interface then that is something that needs to be > raised with the Servlet EG. > > > 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 > >
