On Mon, Sep 16, 2013 at 12:09 PM, Mark Thomas <ma...@apache.org> wrote:
> On 16/09/2013 10:00, Niki Dokovski wrote: > > On Fri, Sep 13, 2013 at 9:27 PM, Niki Dokovski <nick...@gmail.com> > wrote: > > > >> > >> > >> > >> On Fri, Sep 13, 2013 at 8:55 PM, Nick Williams < > >> nicho...@nicholaswilliams.net> wrote: > >> > >>> > >>> On Sep 13, 2013, at 12:42 PM, Igor Urisman wrote: > >>> > >>>> I couldn't agree more. WebSocket is provided by the container. But > the > >>>> time any app code gets to run, Spring of Fall, container ought to be > >>> done. > >>>> -Igor. > >>>> > >>>> > >>>> On Fri, Sep 13, 2013 at 10:38 AM, Christopher Schultz < > >>>> ch...@christopherschultz.net> wrote: > >>>> > >>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> Hash: SHA256 > >>>>> > >>>>> Konstantin, > >>>>> > >>>>> On 9/13/13 7:50 AM, Konstantin Kolinko wrote: > >>>>>> I see no issue here, as both WebSocket implementation and Spring's > >>>>>> WebApplicationInitializer rely on use of > >>>>>> "javax.servlet.ServletContainerInitializer" to initialize > >>>>>> themselves. > >>>>>> > >>>>>> Reading the Servlet specification 3.1, I see no words in the > >>>>>> specification on the ordering of ServletContainerInitializer > >>>>>> instances. (It would be reasonable that they were covered by ch. > >>>>>> "8.2.2 Ordering of web.xml and web-fragment.xml", but I see no > >>>>>> explicit wording there). > >>>>> > >>>>> The fact that Tomcat uses an SCI is an implementation detail, so I'm > >>>>> not sure the spec is relevant. I think it's reasonable for an SCI to > >>>>> expect that the environment Tomcat provides is available without > >>>>> having to resort to implementation-specific hacks like re-ordering > >>>>> their own SCIs with respect to Tomcat's. > >>> > >> > >>> The problem of SCIs and ordering is one that will surely be a matter of > >>> extensive discussion for Servlet 3.2. I intend to lobby heavily for a > >>> solution to SCI ordering in Servlet 3.2; importantly, a solution that > uses > >>> existing facilities so that 3.0 and 3.1 containers can implement it > >>> retroactively with the existing API. > >>> > >>> From a discussion Mark and I had several months ago, Tomcat actually > >>> orders SCIs according to the web fragment ordering. This isn't > portable, > >>> because it's not required in the spec--some containers do this, others > >>> don't. The Spring web fragment has no defined order (see [1]). > However, you > >>> can define an absolute order in your deployment descriptor (web.xml): > >>> > >>> <absolute-ordering> > >>> <others /> > >>> <name>spring_web</name> > >>> </absolute-ordering> > >>> > >>> Since Tomcat orders SCIs according to web-fragment order, this /should/ > >>> work. However, I don't know whether container-provided SCIs abide by > this. > >>> For example: In Jetty, container SCIs always come before application > SCIs > >>> (and if Tomcat did this, you wouldn't be having a problem). > >>> > >> > >> Chris is correct that this is an implementaion detail and current > >> implementation uses initialization mechanism which is not precise. Since > >> the container exposes the ws implementation and by the spec the > >> ServletContext should contain the ServerContainer implementaion as > >> attribute, I expect that to be found in whatevet application related > >> framework I use. Perhaps the implementaion can be improved in way that > >> WsSci is invoked first. > >> > >> Ordering of SCIs is still a problem for Servlet 3.2. > >> > > > > Mark, what is your opinion on the topic? I looked at the implementation > of > > WebappServiceLoader and perhaps it could be improved in a sense of the > > ordering of the web-fragments. What I noticed is that the jars of the > > web-fragments are processed according the ordering defined in the > > descriptors. WebappServiceLoader public Collection<T> load(Class<T> > > serviceType). However the results of the processing are put in a > collection > > with unpredictable iteration order (servicesFound), Hence later when the > > results are obtained from the scanned resources and new instances of SCis > > are obtained the instantiation order is undefined. > > > > Thoughts? > > The only requirement on ordering is at the end of section 8.2 which > requires that application SCIs are discovered before container SCIs. > That is the opposite to what is being requested here. > > The issue needs to be raised with the EG. I'd suggest you create a JIRA. > Here is one created by Nick. https://java.net/jira/browse/SERVLET_SPEC-79 > > Mark > > > > > > >> Someone more familiar with the implementation (like Mark) could > >>> undoubtedly tell you whether this will work, but it won't hurt to try. > >>> Again, if it does work, it may only work in Tomcat; it might not work > in > >>> any other containers. > >>> > >>> [1] > >>> > https://github.com/spring-projects/spring-framework/blob/master/spring-web/src/main/resources/META-INF/web-fragment.xml > >> > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
