tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niki Dokovski <nick...@gmail.com>
Subject Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
Date Fri, 13 Sep 2013 18:27:28 GMT
On Fri, Sep 13, 2013 at 8:55 PM, Nick Williams <
nicholas@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 <
> > chris@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.

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message