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? > 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 > > >
