jsr356-experts@websocket-spec.java.net

[jsr356-experts] Re: connectToServer

From: Scott Ferguson <ferg_at_caucho.com>
Date: Wed, 27 Feb 2013 17:30:29 -0800

On 2/27/13 4:47 PM, Danny Coward wrote:
> My apologies to Scott to have left it so late to respond to this
> change. In part I was waiting until we had cleaned up the
> *Configuration/Configurator API, which I think we have now, as of
> v013. Here is today's API:-
>
> WebSocketContainer {
> Session connectToServer(Class<?> annotatedEndpointClass, URI path)
> throws DeploymentException, IOException;
> Session connectToServer(Class<? extends Endpoint> endpointClass,
> ClientEndpointConfiguration cec, URI path) throws DeploymentException,
> IOException;
> }
>
> I think since this came up, we have embraced the CDI instantiation
> when this API is in a Java EE container. This obviously brings the
> benefits of being able to inject EJBs and CDI managed beans into
> websocket endpoints, the bread and butter for Java EE developers, and
> which forces a model where the implementation is doing the instantiation.

No.

It's just false that CDI "forces a model where the implementation is
doing the instantiation" on the client side.

A client in a Java EE container is fully capable of instantiating its
own CDI-injected endpoint before calling connectToServer, either with
@Inject Endpoint, or @Inject Instance<Endpoint> or from the BeanManager
directly, or even from basic encapsulation of its own injection points.
It already has access to EJBs and everything.

The client already has all the features you list.

Besides, if you do want ClientWebSocketContainer to instantiate under
CDI, you really should be using:

   BeanManager.getBeans(Type beanType, Annotation... qualifiers)

Please note the qualifiers. If you're calling with just the Class<?>,
and stripping the qualifiers, you're using CDI incorrectly, (and thereby
taking power away from the client). The API really needs to be:

   connectToServer(URI path, Type endpointType, Annotation... qualifiers);

>
> We have also added the concept of allowing Configurators to control
> endpoint instance creation on the server side.
>
> So if we still feel this is a relevant use case, my thought is we
> could add the analogous factory method to the ClientEndpointConfigurator.

Clients don't need factories.

On the server side, that factory is needed because server endpoints are
created on demand as requests come in. On servers, new endpoints are not
under the server's control. It's a reactive model and requires some kind
of factory.

On a client, the client knows when it wants to create an endpoint.
That's the whole point of connectToServer. That's what it does. There's
no need for any reactive API.

Client and server are not symmetrical in this case.

>
> Or we could simply add the deploy by endpoint instance methods Scott
> has proposed. (we still need the deploy by class/config for the EE folks).

Please explain why you think EE doesn't have CDI already available.

-- Scott
>
> What is the group feeling ?
>
> - Danny
>
>
>
>
>
>
>
> On 1/14/13 8:32 AM, Scott Ferguson wrote:
>> The new connectToServer is difficult to use.
>>
>> Instead of a Class parameter, it should be an object. The container
>> shouldn't need to instantiate the object, and the Class model makes
>> it difficult to connect between the client application and the client
>> endpoint. (Because any shared state/object needs to be passed through
>> a custom ClientEndpointConfiguration.)
>>
>> The API should be simplified to:
>>
>> WebSocketContainer {
>> Session connectToServer(Object endpoint, URI path);
>>
>> Session connectToServer(Object endpoint, URI path,
>> ClientEndpointConfiguration cec);
>> }
>>
>> If the "endpoint" object is already of type Endpoint, it's used
>> directly. Otherwise, a skeleton/proxy is created, i.e. annotation stuff.
>>
>> There's no need for separate methods for Endpoint vs annotation.
>>
>> -- Scott
>>
>
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>