On 05/12/2014 19:11, Rémy Maucherat wrote: > 2014-12-05 19:52 GMT+01:00 Mark Thomas <ma...@apache.org>: > >> On 05/12/2014 08:42, r...@apache.org wrote:
<snip/> >>> + // Configuration for extensions >>> + static final boolean DISABLE_BUILTIN_EXTENSIONS = >>> + >> Boolean.getBoolean("org.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS"); >>> + static final boolean ALLOW_UNSUPPORTED_EXTENSIONS = >>> + >> Boolean.getBoolean("org.apache.tomcat.websocket.ALLOW_UNSUPPORTED_EXTENSIONS"); >>> + >> >> I'm against adding both of the above solely to work around broken TCK >> tests. Do they have any real world use case? >> > > They're trying to test the existing APIs, the user indeed has a (rather > well hidden) way to set its own extensions. So this is rather legitimate. Yes, but without the ability to add an implementation of that extension there is no point to the user setting their own extensions. > But then you would like to throw an error. Fine with me, but things go both > ways: unless there's something in the spec which says the server should > throw an error if it doesn't know an extension, then it should be > acceptable to at least have an option for that behavior. I still think that throwing an Deployment error is the only sensible behaviour if an application tries to set its own extension. I do take the point about the API being there. If it can not be used for anything, what is the point of even having it. The more I think about this, the more I think it made no sense to include extensions on the server side without an API to add extension implementations. But that boat has sailed. I appreciate that these options are necessary in order to pass the TCK and I don't want to get in the way of that. How about the following: - keep the two options as above - mark them as deprecated with some text to the effect that they are only present to enable the TCK to pass for the WebSocket 1.1 API and they are expected to be removed once the WebSocket API includes a mechanism for adding custom extension implementations. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org