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
