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