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 Mon, 16 Sep 2013 09:00:41 GMT
On Fri, Sep 13, 2013 at 9:27 PM, Niki Dokovski <nickytd@gmail.com> wrote:

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

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

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