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
