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