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). *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:54, Romain Manni-Bucau wrote: > >> that's what we do in TomEE but i don't get how a SCI (order is not >> deterministic IIRC) can solve the issue. >> > > You have yet to articulate exactly what the issue is. > > You are correct that SCI processing order is not fully deterministic. > > Container SCIs are under the control of the container so can be processed > in any order the container sees fit so that part can be deterministic. > > Application SCIs do not have an order defined. If that is a problem, raise > it with the EG. I'd suggest the simple solution (which Tomcat already > implements) is to treat JARs without a fragment as if it contains an empty > fragment and then process SCIs in the same order as fragments are processed. > > > 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 > >
