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