On Sep 16, 2013, at 4:09 AM, Mark Thomas 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.
Actually, that's not exactly what it says (quoted from 8.2.4):
> Implementations of the ServletContainerInitializer interface will be
> discovered by the runtime's service lookup mechanism or a container specific
> mechanism that is semantically equivalent to it. In either case,
> ServletContainerInitializer services from web fragment JAR files that are
> excluded from an absolute ordering MUST be ignored, and the order in which
> these services are discovered MUST follow the application’s class loading
> delegation model.
A lot of this depends on what your definition of "discovered" means. If
"discovered" means "invoked" (I would suggest it does not), this sounds to me
to mean that the container SCIs must run first if the container class loader is
prioritized first ("parent first class loading," optional in Tomcat), and the
application SCIs must run first if the container class loader is prioritized
last ("parent last class loading," the default in Tomcat). But I don't think
that's what it means. Can you point to a clarification anywhere in which
"discover" is defined as "invoke?" That would be helpful, if so.
Assuming "discover" means "invoke:"
Does the WS spec require that WS be initialized in an SCI? Or does it just
suggest it? If it just suggests it, then I would suggest an SCI is the wrong
place for this initialization. (If we're planning on initializing JSP in an
SCI, I would suggest that's the wrong place for it, too.) I agree with the
general sentiment being expressed here that the container should be done
initializing its components before it runs any application code, including any
application SCIs (importantly, the WS servlet context attribute should be set).
That means that this initialization should take place before application SCIs
are run. If application SCIs absolutely must run first, then this
initialization should happen some way other than an SCI, IMO.
Nick
>
> The issue needs to be raised with the EG. I'd suggest you create a JIRA.
>
> 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
>
smime.p7s
Description: S/MIME cryptographic signature
