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:53:40 GMT
On Mon, Sep 16, 2013 at 12:09 PM, Mark Thomas <markt@apache.org> wrote:

> On 16/09/2013 10:00, Niki Dokovski wrote:
> > 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?
>
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

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