You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Igor Urisman <ig...@gmail.com> on 2013/09/13 06:56:37 UTC
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
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.
Many thanks,
-Igor.
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Niki Dokovski <ni...@gmail.com>.
On Fri, Sep 13, 2013 at 7:56 AM, Igor Urisman <ig...@gmail.com>wrote:
> 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.html>to
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.
Posted by Niki Dokovski <ni...@gmail.com>.
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 <ni...@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
>
>
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Niki Dokovski <ni...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Niki Dokovski <ni...@gmail.com>.
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-unsubscribe@tomcat.apache.org <javascript:;>
> For additional commands, e-mail: users-help@tomcat.apache.org<javascript:;>
>
>
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@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.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Mark Thomas <ma...@apache.org>.
On 16/09/2013 10:00, Niki Dokovski wrote:
> On Fri, Sep 13, 2013 at 9:27 PM, Niki Dokovski <ni...@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.
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
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Niki Dokovski <ni...@gmail.com>.
On Fri, Sep 13, 2013 at 9:27 PM, Niki Dokovski <ni...@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
>
>
>
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Niki Dokovski <ni...@gmail.com>.
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
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute gets set too late.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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).
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.
Posted by Igor Urisman <ig...@gmail.com>.
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.
>
> - -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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 8.0.0 RC1: WebSocket ServerContainer servlet context attribute
gets set too late.
Posted by Konstantin Kolinko <kn...@gmail.com>.
2013/9/13 Igor Urisman <ig...@gmail.com>:
> 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.
>
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org