Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
On 16/09/2013 17:37, Nick Williams wrote: On Sep 16, 2013, at 11:21 AM, Mark Thomas wrote: It certainly looks at this point as if the order is anything you like. Personally, I'd prefer something rather more deterministic. Agreed. That's why I filed [1]. I've added a comment on some additional complications and a proposal. My understanding based on our previous conversations is that Tomcat *currently* orders SCIs according to the web-fragment ordering. Looking back on those conversations, what's not clear to me now is: 1) How does Tomcat *currently* order the groups of SCIs? Container before application or application before container? I *think* the answer is always application before container. It is. 2) Does web-fragment ordering *currently* affect whether container SCIs come before application or vice versa? I *think* the answer is it does not. It did. I'm not sure either after the recent(ish) refactoring. It would be great if any existing JCP members could bring [1] to their attention and maybe get some people together for a discussion. Based on previous experience of how the Servlet EG works the only opinion that matters is what the EG lead decides and until that decision is in writing... Tomcat doesn't have the information it needs to correctly order the SCIs at the moment, regardless of what ordering scheme is eventually chosen. On reflection, I can see the need to at least partially address this issue prior to the EG making a final decision. Therefore I intend to do the following: 1. Refactoring 8.0.x and 7.0.x to make the information available to enable various ordering schemes to be implemented. 2. Ensure that application provided SCIs are still executed in web fragment order. (Up to this point this work should result in no functional changes unless other refactorings have introduced unintended changes) 3. Change the current order to execute container provided SCIs first. Implementing point 3 should address the immediate issue without generating too much nugatory work if the EG opts for a completely different scheme. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
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 / namespring_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 CollectionT load(ClassT 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
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
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 / namespring_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 CollectionT load(ClassT 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. 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
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
On Mon, Sep 16, 2013 at 12:09 PM, Mark Thomas ma...@apache.org 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 / namespring_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 CollectionT load(ClassT 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
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 / namespring_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 CollectionT load(ClassT 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
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/16/13 5:09 AM, Mark Thomas wrote: 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. While raising the issue with the EG might be appropriate, there's no mandate from the EG that WebSocket services be initialized from an SCI. I see this as a Tomcat problem, not a spec problem. I believe it's reasonable for webapp code to expect a sane environment during initialization. In this case, an architectural decision at the container-implementation level (to use an SCI to get WebSocket going) has collided with a reasonable expectation of a webapp implementer. I don't believe the solution is to have the EG rule on this... the solution is to make Tomcat meet expectations. If that means changing from using an SCI to some other mechanism, obviously the EG's opinion is moot. If you want to get the EG's ruling and then work within that construct to get Tomcat's WebSocket SCI working nicely in the above scenario, that's fine. But you shouldn't use an unfavorable (or useless) ruling by the EG as cover for not supporting this use case. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSNxPsAAoJEBzwKT+lPKRY99UP/Rt2D/c9NYATnRcvDEmE7Zu9 ey1cyJ8vdcfqb3xKZKEG/N1EPwxRds8NmkuP/B4Z1uAtrV6g84DIyuBfKVg+/IZm fyzLZG55A8GPNfiuoe5ajT4TqmhI8ngg3oYfYy42RCd8sUPWI/T3CXNAA07khLS4 E5o5bbZ+JAV4RptyLGJsdZDceijrxPKWl3KmKKTByn7hGTmcCHSlGbYmdPXJ5oMr QX3phw7Qb42u+smpPZ1XcE2pfYy8lhJE/LlbxgWWHIaK+fSod2O9cy1U0Ls1V4kG MIA0Vlglr5+FXPwJfW9BzNZ5pDsqAN80ip4Sk91MWiHcPscWdXRIvZS8Yjv3KVi6 r88q1F/FONClI7CxLnE0GcTjP8ZHOqVZzCxJF9CHP1pRjhEtsUEYBNe5MqXkDwE+ rDrlfwPnIAMUOdz6DeFX1es/p+k6adDaKIj+vzHtcWyeOekp1zjHFIyoO+ClmmiR mv/VI4RXIn9PuUzaUruGojiJ+gzk4UCupoJ4EamiNBKXko9P5PBXFmszBJY7LlZY GpWcudMTdyDE/E8ht1zWSnaSvIusbkQR+5WVTXONAOT+a2oGwqKJ8MCbb3opykG8 Vu6CAKisz67Qb9LhM2Jj6Xa6dtfXBBjlxDfJbadWcORst2hX4Jx0kag0czHyROHz VyMgKgN3NwCuoRTgKcah =z09t -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
On 16/09/2013 15:21, Christopher Schultz wrote: Mark, On 9/16/13 5:09 AM, Mark Thomas wrote: 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. While raising the issue with the EG might be appropriate, there's no mandate from the EG that WebSocket services be initialized from an SCI. I see this as a Tomcat problem, not a spec problem. If you read the Servlet spec it is clear that SCIs are intended for adding capability such as WebSocket. The example used is JSP support which is clearly in the same category. I believe it's reasonable for webapp code to expect a sane environment during initialization. In this case, an architectural decision at the container-implementation level (to use an SCI to get WebSocket going) has collided with a reasonable expectation of a webapp implementer. I don't believe the solution is to have the EG rule on this... the solution is to make Tomcat meet expectations. The issue is with the lack of clarity from the EG with respect to ordering. I read section 8.2 one way but it is open to interpretation. Rather than change Tomcat once, then get clarification from the EG and then have to change it again, I'd rather get clarification first and then make any necessary changes. Clearly, there are going to have to be changes. I can think of several ways to tackle this issue. I'd rather design the solution with the EG mandated behaviour (even if that is 'we don't care') in mind. If that means changing from using an SCI to some other mechanism, That isn't going to happen. obviously the EG's opinion is moot. If you want to get the EG's ruling and then work within that construct to get Tomcat's WebSocket SCI working nicely in the above scenario, that's fine. But you shouldn't use an unfavorable (or useless) ruling by the EG as cover for not supporting this use case. I am not looking for excuses not to support the use case. I am looking for those that care about this issue to do the work of getting clarification from the EG. This isn't an environment where someone just throws a problem over the wall and waits for someone else to fix it. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
On Monday, September 16, 2013, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/16/13 5:09 AM, Mark Thomas wrote: 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. While raising the issue with the EG might be appropriate, there's no mandate from the EG that WebSocket services be initialized from an SCI. I see this as a Tomcat problem, not a spec problem. I'm willing to take a look at the issue in the next few days and propose smth for review. Niki I believe it's reasonable for webapp code to expect a sane environment during initialization. In this case, an architectural decision at the container-implementation level (to use an SCI to get WebSocket going) has collided with a reasonable expectation of a webapp implementer. I don't believe the solution is to have the EG rule on this... the solution is to make Tomcat meet expectations. If that means changing from using an SCI to some other mechanism, obviously the EG's opinion is moot. If you want to get the EG's ruling and then work within that construct to get Tomcat's WebSocket SCI working nicely in the above scenario, that's fine. But you shouldn't use an unfavorable (or useless) ruling by the EG as cover for not supporting this use case. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSNxPsAAoJEBzwKT+lPKRY99UP/Rt2D/c9NYATnRcvDEmE7Zu9 ey1cyJ8vdcfqb3xKZKEG/N1EPwxRds8NmkuP/B4Z1uAtrV6g84DIyuBfKVg+/IZm fyzLZG55A8GPNfiuoe5ajT4TqmhI8ngg3oYfYy42RCd8sUPWI/T3CXNAA07khLS4 E5o5bbZ+JAV4RptyLGJsdZDceijrxPKWl3KmKKTByn7hGTmcCHSlGbYmdPXJ5oMr QX3phw7Qb42u+smpPZ1XcE2pfYy8lhJE/LlbxgWWHIaK+fSod2O9cy1U0Ls1V4kG MIA0Vlglr5+FXPwJfW9BzNZ5pDsqAN80ip4Sk91MWiHcPscWdXRIvZS8Yjv3KVi6 r88q1F/FONClI7CxLnE0GcTjP8ZHOqVZzCxJF9CHP1pRjhEtsUEYBNe5MqXkDwE+ rDrlfwPnIAMUOdz6DeFX1es/p+k6adDaKIj+vzHtcWyeOekp1zjHFIyoO+ClmmiR mv/VI4RXIn9PuUzaUruGojiJ+gzk4UCupoJ4EamiNBKXko9P5PBXFmszBJY7LlZY GpWcudMTdyDE/E8ht1zWSnaSvIusbkQR+5WVTXONAOT+a2oGwqKJ8MCbb3opykG8 Vu6CAKisz67Qb9LhM2Jj6Xa6dtfXBBjlxDfJbadWcORst2hX4Jx0kag0czHyROHz VyMgKgN3NwCuoRTgKcah =z09t -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org javascript:; For additional commands, e-mail: users-h...@tomcat.apache.orgjavascript:;
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
On 16/09/2013 16:57, Mark Thomas wrote: The issue is with the lack of clarity from the EG with respect to ordering. I read section 8.2 one way but it is open to interpretation. I've dug back through the Servlet 3.0 mailing list. The text at the end of section 8.2 is aimed at the case where the same SCI implementation exists in the container and the web app. It doesn't appear that it was intended to affect ordering. There are a number of grey areas that were raised at the same time that have not been resolved. Ordering was one. How to handle the case where an SCI is provided by the container and the web app but excluded from the web app via ordering was another. It certainly looks at this point as if the order is anything you like. Personally, I'd prefer something rather more deterministic. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 9/16/13 11:57 AM, Mark Thomas wrote: On 16/09/2013 15:21, Christopher Schultz wrote: Mark, On 9/16/13 5:09 AM, Mark Thomas wrote: 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. While raising the issue with the EG might be appropriate, there's no mandate from the EG that WebSocket services be initialized from an SCI. I see this as a Tomcat problem, not a spec problem. If you read the Servlet spec it is clear that SCIs are intended for adding capability such as WebSocket. The example used is JSP support which is clearly in the same category. I believe it's reasonable for webapp code to expect a sane environment during initialization. In this case, an architectural decision at the container-implementation level (to use an SCI to get WebSocket going) has collided with a reasonable expectation of a webapp implementer. I don't believe the solution is to have the EG rule on this... the solution is to make Tomcat meet expectations. The issue is with the lack of clarity from the EG with respect to ordering. I read section 8.2 one way but it is open to interpretation. Rather than change Tomcat once, then get clarification from the EG and then have to change it again, I'd rather get clarification first and then make any necessary changes. Clearly, there are going to have to be changes. I can think of several ways to tackle this issue. I'd rather design the solution with the EG mandated behaviour (even if that is 'we don't care') in mind. If that means changing from using an SCI to some other mechanism, That isn't going to happen. obviously the EG's opinion is moot. If you want to get the EG's ruling and then work within that construct to get Tomcat's WebSocket SCI working nicely in the above scenario, that's fine. But you shouldn't use an unfavorable (or useless) ruling by the EG as cover for not supporting this use case. I am not looking for excuses not to support the use case. I am looking for those that care about this issue to do the work of getting clarification from the EG. This isn't an environment where someone just throws a problem over the wall and waits for someone else to fix it. Sorry, I didn't mean to suggest that you were actually looking for a reason to ignore the problem. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSNzB5AAoJEBzwKT+lPKRYAnMP/RzRhc0HJ80uE0rwMwfy4N+X lgy5A5vFLCox5WloT1se80lqgMXEWgJPpMF/9qZv2mrmu5wTnEZQoZh2O8iwYt6Q zOP2YKj8KmbAZhrse1Ui+DBNwbzdVV2Ek5xuSqahvSpoU31sLUhDsx893NAp/tYi Q62O9V/7fso2d2z5TbzdrWqWsLwrm2HYp0nrCIZhkZjw46lZnza2SLNs++/CP4OF 4BJgdcojh6B7UN0v9nNaFr0xdQ+2wqIDv73XdCoq311yRaB1kH5FIXJDtTFuC1/9 fruWDDz1oIB7B8qJKMTPhWIa1fzAxx/dfLUkDMyT59nInkXtvNS7Xs3eb1kWM9Kn IO1WPTY1jstFqYLndxpYAJzb/0Mo5ugPB//Ph62w4bX+6EN7VExw7fK5pANDLLuI qjDg0j2/lLm4KXQi2eYUzKMxQiIc9RhHqa98xMp5NqToW3bwL2wRUa3Pd7TojSc+ +zgW4Ho8oxkSpL96OTJ5fAyyptZ7kxUr+gWsOszRjWGwCjP6iq2KYsAo4BVqm1SY URFG3wArhX+u0IuN2dhmY7SjPiA98dQG3Rdv7T+yzfHVDqnlQZCPW9D4xTeHDrfC hsNdPKymYiV+rCzWDFRY7DFuBmnE+c0wCpSh+AJQv9/OOYweeHY692qf43aSBOH7 5eutoqXpNWCUgbn3N4AX =q9aQ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
On Sep 16, 2013, at 11:21 AM, Mark Thomas wrote: On 16/09/2013 16:57, Mark Thomas wrote: The issue is with the lack of clarity from the EG with respect to ordering. I read section 8.2 one way but it is open to interpretation. I've dug back through the Servlet 3.0 mailing list. The text at the end of section 8.2 is aimed at the case where the same SCI implementation exists in the container and the web app. It doesn't appear that it was intended to affect ordering. There are a number of grey areas that were raised at the same time that have not been resolved. Ordering was one. How to handle the case where an SCI is provided by the container and the web app but excluded from the web app via ordering was another. It certainly looks at this point as if the order is anything you like. Personally, I'd prefer something rather more deterministic. Agreed. That's why I filed [1]. My understanding based on our previous conversations is that Tomcat *currently* orders SCIs according to the web-fragment ordering. Looking back on those conversations, what's not clear to me now is: 1) How does Tomcat *currently* order the groups of SCIs? Container before application or application before container? I *think* the answer is always application before container. 2) Does web-fragment ordering *currently* affect whether container SCIs come before application or vice versa? I *think* the answer is it does not. IMO, SCI ordering should be the same as web-fragment ordering. With that said, that's the suggestion I made in [1]. Unfortunately, there have been no comments from the EG yet. I know it will be a while before they start working on Servlet 3.2, but my hope was to get the EG involved on this particular issue early, so that some guidance can be given to 3.0 and 3.1 containers for how they might tweak their existing behavior (if possible, if the API doesn't change any) to provide consistent behavior across containers (JBoss also uses web-fragment ordering, and WebLogic and WebSphere appear to as well, but Jetty, GlassFish, and Resin use the order as returned from the ClassLoader). Consistency in Servlet 3.0 and 3.1 containers would be a high win, IMO. I'm trying to join the JCP as an individual process so that I can, hopefully, be a little more influential in this process. Unfortunately the process is onerous and it appears that I will not be allowed to join. (As an individual, my employer, who has absolutely no control or say over what I do in my spare time, is required to sign Exhibit B saying they won't claim ownership of my contributions, but my employer won't sign it because it's unnecessary and serves no business purpose to us to enter into a legally binding agreement for you to do something that we don't care about on your own time.) It would be great if any existing JCP members could bring [1] to their attention and maybe get some people together for a discussion. N [1] https://java.net/jira/browse/SERVLET_SPEC-79 smime.p7s Description: S/MIME cryptographic signature
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
On Mon, Sep 16, 2013 at 6:57 PM, Mark Thomas ma...@apache.org wrote: On 16/09/2013 15:21, Christopher Schultz wrote: Mark, On 9/16/13 5:09 AM, Mark Thomas wrote: 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. While raising the issue with the EG might be appropriate, there's no mandate from the EG that WebSocket services be initialized from an SCI. I see this as a Tomcat problem, not a spec problem. If you read the Servlet spec it is clear that SCIs are intended for adding capability such as WebSocket. The example used is JSP support which is clearly in the same category. I believe it's reasonable for webapp code to expect a sane environment during initialization. In this case, an architectural decision at the container-implementation level (to use an SCI to get WebSocket going) has collided with a reasonable expectation of a webapp implementer. I don't believe the solution is to have the EG rule on this... the solution is to make Tomcat meet expectations. The issue is with the lack of clarity from the EG with respect to ordering. I read section 8.2 one way but it is open to interpretation. Rather than change Tomcat once, then get clarification from the EG and then have to change it again, I'd rather get clarification first and then make any necessary changes. Clearly, there are going to have to be changes. I can think of several ways to tackle this issue. I'd rather design the solution with the EG mandated behaviour (even if that is 'we don't care') in mind. If that means changing from using an SCI to some other mechanism, That isn't going to happen. obviously the EG's opinion is moot. If you want to get the EG's ruling and then work within that construct to get Tomcat's WebSocket SCI working nicely in the above scenario, that's fine. But you shouldn't use an unfavorable (or useless) ruling by the EG as cover for not supporting this use case. I am not looking for excuses not to support the use case. I am looking for those that care about this issue to do the work of getting clarification from the EG. This isn't an environment where someone just throws a problem over the wall and waits for someone else to fix it. It's prefereable to have the EG clear the issue and then implement accordingly. However the Java EE 7 was just published and I don't expect any changes soon. I think SCI ordering is a topic leading to a release of the spec. This case is not just a clarification. It is related to spec text updates and probably changes in the compatability test set as well. I don't know whether there are ongoing internal EG discussions but there are no public comments on the JIRA issue. It is the same with WebSocket EG - there are number of issues without any comments. JavaOne 2013 is around corner and if someone is visiting perhaps face to face with someone from EG could be arranged. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
Dear all,
It appears that if I obtain the ServletContext object via Spring's
WebApplicationInitializer
mechanismhttp://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/WebApplicationInitializer.html,
it is not yet seeded with the WebSocket ServerContainer object.
Alternatively, if I use straight up ServletContextListener, all's good.
More specifically, this works:
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.annotation.WebListener;
@WebListener
public class ServletBootstrapper implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
ServerContainer serverContainer = (ServerContainer)
sc.getAttribute(javax.websocket.server.ServerContainer);
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
// NO-OP
}
}
But this doesn't:
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import org.springframework.web.WebApplicationInitializer;
public class SpringBootstrapper implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext sc) throws ServletException {
// Next line returns null
ServerContainer serverContainer = (ServerContainer)
sc.getAttribute(javax.websocket.server.ServerContainer);
}
}
I verified that the ServletContext object returned in both is the same, so
that part is good.
I imagine the root cause is that Spring uses an earlier container event to
post implementations of the WebApplicationInitializer interface, before the
ServerContainer attribute is set by the WebSocket code. Given the ubiquity
of Spring, this may prove problematic.
Many thanks,
-Igor.
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
2013/9/13 Igor Urisman igor.uris...@gmail.com:
Dear all,
It appears that if I obtain the ServletContext object via Spring's
WebApplicationInitializer
mechanismhttp://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/WebApplicationInitializer.html,
it is not yet seeded with the WebSocket ServerContainer object.
Alternatively, if I use straight up ServletContextListener, all's good.
More specifically, this works:
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.annotation.WebListener;
@WebListener
public class ServletBootstrapper implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
ServerContainer serverContainer = (ServerContainer)
sc.getAttribute(javax.websocket.server.ServerContainer);
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
// NO-OP
}
}
But this doesn't:
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import org.springframework.web.WebApplicationInitializer;
public class SpringBootstrapper implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext sc) throws ServletException {
// Next line returns null
ServerContainer serverContainer = (ServerContainer)
sc.getAttribute(javax.websocket.server.ServerContainer);
}
}
I verified that the ServletContext object returned in both is the same, so
that part is good.
I imagine the root cause is that Spring uses an earlier container event to
post implementations of the WebApplicationInitializer interface, before the
ServerContainer attribute is set by the WebSocket code. Given the ubiquity
of Spring, this may prove problematic.
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).
If 8.2.2 indeed implies the ordering of those, then you can specify
absolute ordering in your web.xml or relative ordering in your
web-fragment.xml. If it does not work with Tomcat then file an issue.
If specification does not cover the ordering, or you do not want to
configure it, then you have to fall back to using a
ServletContextListener.
(You should be able to use WebApplicationInitializer to install an
instance of ServletContextListener for you).
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
On Fri, Sep 13, 2013 at 7:56 AM, Igor Urisman igor.uris...@gmail.comwrote:
Dear all,
It appears that if I obtain the ServletContext object via Spring's
WebApplicationInitializer
mechanism
http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/web/WebApplicationInitializer.html
,
it is not yet seeded with the WebSocket ServerContainer object.
Alternatively, if I use straight up ServletContextListener, all's good.
More specifically, this works:
import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;
import javax.servlet.annotation.WebListener;
@WebListener
public class ServletBootstrapper implements ServletContextListener {
@Override
public void contextInitialized(ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
ServerContainer serverContainer = (ServerContainer)
sc.getAttribute(javax.websocket.server.ServerContainer);
}
@Override
public void contextDestroyed(ServletContextEvent sce) {
// NO-OP
}
}
But this doesn't:
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import org.springframework.web.WebApplicationInitializer;
public class SpringBootstrapper implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext sc) throws ServletException {
// Next line returns null
ServerContainer serverContainer = (ServerContainer)
sc.getAttribute(javax.websocket.server.ServerContainer);
}
}
I verified that the ServletContext object returned in both is the same, so
that part is good.
I imagine the root cause is that Spring uses an earlier container event to
post implementations of the WebApplicationInitializer interface, before the
ServerContainer attribute is set by the WebSocket code. Given the ubiquity
of Spring, this may prove problematic.
WebSocket implementation uses a ServletContainerInitializer
http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContainerInitializer.htmlto
register the servlet context attribute. This can be observed in WsSci
implementation.
The servlet spec does not guarantees an order of invocations of SCIs. A
good problem description can be found here
https://java.net/jira/browse/GLASSFISH-20788 Without knowing the Spring
implementation can you check whether this is a ordering problem? The spring
SCI is invoked before WsSci.
cheers
Niki
Many thanks,
-Igor.
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
-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. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSM02MAAoJEBzwKT+lPKRYEuQP/3OK1OZj4LGRTl8PlkVZ/VQ2 gWEpIeLmXAxmr4WIO666dtd/BhcB1oLc2TXkqMMmThnYO4u8wl0nlFh8IlIk4y2z /2OPbyd4tUhpvhk5R63xFqifbyKXFnvQVAeFlc9KdAhJ61TYGjJbNF6sUCY65Sa2 e6kvhoTCx/E8LuoBOsQwuQo/tcpZZfXrwqtF1EQj/8imWhnM8eKjvD+TtaNtVKFj kL5Vf4gL2ti3U9EVtlqEF+ul4AEnTWCw9nZukv+mbRlMe157LIKd0aY0y3Kft4D3 3tVdp5TuB8T+grycrkENr8g/AyPPnaUD/tkLTkSeQQDWbxufMTSIsamEkPLVioXG I19N0eetB0CnRu0moO9PINEGHcEEFkCUGi0yG8x+LKpQ0nqG6eTeBM2VFolX1dur h1a0RWqnCqu/bSv3U3psDZofxLYpDrAOCESNXUFhowMRswhS5zrkihN42YKWJ6FN 1/RUlhHB2msf/UbAK+WDhQbqf5yhgBP0871pUfWh4VdQdUWFmyIRltNqt8aDtTJ1 p/XoWTkMEeCQLDpA2S1iLdkHKfUGAOycjak6qa+6552k42nErsHDaMZ0dagYO4dv BiRQdLp0T3Kcfrjpr9DjKOgmk7aBnAgKLGMNBD2MT4Tir8QCnRrGIYTtBRpBXG+q aECZxgxMa8mdQWNQQ0Cj =UJf1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
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. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSM02MAAoJEBzwKT+lPKRYEuQP/3OK1OZj4LGRTl8PlkVZ/VQ2 gWEpIeLmXAxmr4WIO666dtd/BhcB1oLc2TXkqMMmThnYO4u8wl0nlFh8IlIk4y2z /2OPbyd4tUhpvhk5R63xFqifbyKXFnvQVAeFlc9KdAhJ61TYGjJbNF6sUCY65Sa2 e6kvhoTCx/E8LuoBOsQwuQo/tcpZZfXrwqtF1EQj/8imWhnM8eKjvD+TtaNtVKFj kL5Vf4gL2ti3U9EVtlqEF+ul4AEnTWCw9nZukv+mbRlMe157LIKd0aY0y3Kft4D3 3tVdp5TuB8T+grycrkENr8g/AyPPnaUD/tkLTkSeQQDWbxufMTSIsamEkPLVioXG I19N0eetB0CnRu0moO9PINEGHcEEFkCUGi0yG8x+LKpQ0nqG6eTeBM2VFolX1dur h1a0RWqnCqu/bSv3U3psDZofxLYpDrAOCESNXUFhowMRswhS5zrkihN42YKWJ6FN 1/RUlhHB2msf/UbAK+WDhQbqf5yhgBP0871pUfWh4VdQdUWFmyIRltNqt8aDtTJ1 p/XoWTkMEeCQLDpA2S1iLdkHKfUGAOycjak6qa+6552k42nErsHDaMZ0dagYO4dv BiRQdLp0T3Kcfrjpr9DjKOgmk7aBnAgKLGMNBD2MT4Tir8QCnRrGIYTtBRpBXG+q aECZxgxMa8mdQWNQQ0Cj =UJf1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
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 / namespring_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). 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 smime.p7s Description: S/MIME cryptographic signature
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
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 / namespring_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
