jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: TCK 2013-03-20 feedback

From: Danny Coward <danny.coward_at_oracle.com>
Date: Fri, 22 Mar 2013 13:21:50 -0700

On 3/22/13 12:10 PM, Mark Thomas wrote:
> On 22/03/2013 18:30, Danny Coward wrote:
>> Thanks Mark - I'll pass this feedback on.
> Thanks.
>
>> On 1, they haven't caught up to the API for PFD2...which I will release
>> shortly, 2 I agree looks like a bug, and on 3 yes I agree the tests
>> should be using the other method. Perhaps we should disallow that usage
>> with an IllegalArgumentException ? What do you think ?
> Tomcat throws a DeploymentException if the provided class isn't
> annotated with @ClientEndpoint
actually that probably makes more sense.
>
> We could allow the behaviour the TCK is currently using but having the
> same method do very different things depending on if the class extends
> Endpoint doesn't seem very intuitive. Maybe it is just me.

I agree, if the method is described to be for annotated endpoints it
should not be used for programmatic ones.

- Danny
>
> Mark
>
>> - Danny
>>
>>
>> On 3/22/13 3:34 AM, Mark Thomas wrote:
>>> On 22/03/2013 09:42, Mark Thomas wrote:
>>>> TCK changes required
>>>>
>>>> 1. The signature test is still looking for
>>>> ServerEndpointConfig$Configurator.matchesURI which has been removed.
>>>>
>>>> Also [En|De]coder.Adapter and ServerContainerProvider
>>> 2. clientendpointconfig constructor test (and other tests)
>>>
>>> This uses a server endpoint with the following method:
>>> @OnMessage
>>> public void respondString(String message, Session session,
>>> EndpointConfig config)
>>>
>>> The test requires the config parameter to be populated in order to pass
>>> but the Javadoc for @OnMessage makes no reference to EndpointConfig
>>> being a valid parameter for a method annotated with @OnMessage
>>>
>>>
>>> 3. server pathparam directStringParamTest (and a lot of other tests)
>>>
>>> The test calls WebSocketContainer#connectToServer(Class<?>, URI) to
>>> establish the connection to the server. However, it passes a class that
>>> extends Endpoint rather than an annotated POJO. The test should use
>>> WebSocketContainer#connectToServer(Class<? extends Endpoint>,
>>> ClientEndpointConfig, URI)
>>>
>>>
>>> This last point (3) is causing a huge number of test failures. Have I
>>> missed something in the spec or is the TCK wrong here?
>>>
>>>
>>> Mark
>>>
>>>
>>>> Specification questions
>>>>
>>>> 1. Are ServerApplicationConfig instances permitted to return null or
>>>> should they return an empty Set? I had read the Javadoc to mean a Set
>>>> should be returned but some instances in the TCK are returning null.
>>>>
>>>>
>>>> I may have more feedback/questions once I have worked through the
>>>> remaining test failures.
>>>>
>>>>
>>>> Mark
>>>>
>>
>> --
>> <http://www.oracle.com> *Danny Coward *
>> Java EE
>> Oracle Corporation
>>


-- 
<http://www.oracle.com> 	*Danny Coward *
Java EE
Oracle Corporation