Hi Scott,
My apologies, I didn't mean to imply that developers can't use the CDI
APIs themselves to create endpoints that have all the nice injectable
properties we want, or to misrepresent what you are asking for in the
specification.
I suppose I'm trying to find out if folks would like the implementation
to do this for them for client endpoints, as it does in the EE setting
for server endpoints.
Or ask developers to use the CDI APIs themselves if they want the
injectable properties.
Or offer both modes.
- Danny
On 2/27/13 5:30 PM, Scott Ferguson wrote:
> 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
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation