that's what we do in TomEE but i don't get how a SCI (order is not deterministic IIRC) can solve the issue.
*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 08:35, Romain Manni-Bucau wrote: > >> wait SCIs stands for ServletContainerInitializer right? if so just think >> all apps are not only webapps (ear typically) >> > > I'd disagree. I'd say WARs are far more popular than EARs. > > For EARs if there is a case for application wide scanning (not sure there > is but I don't know the rest of the J2EE spec well enough to be certain) > then such scanning needs to be provided by the container in the same way > SCIs provide scanning in Servlet containers. In a full J2EE container it > should be possible for the results of the application wide scan to be fed > to the SCI so there is no need for multiple scans. > > > + the issue is really tomcat scanning shouldn't occur if already done >> (or the opposite, myfaces should >> reuse tomcat scanned info is here, cxf, spring, cdi container...). >> > > Then MyFaces should use an SCI. As should any other library that needs to > scan the WAR for classes and/or annotations in a Servlet container. If > there is something one of these libraries needs that can't be done with an > SCI then that needs to be raised with the Servlet EG. > > The downside of using an SCI is that it requires Servlet 3. Some library > developers may not like the idea of introducing a dependency on Servlet > 3.0. I'd suggest the way forward is to use an SCI if available and if not, > then fall-back to whatever internal scanning is currently used. > > > 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 > >
