Hi folks,
So that we can close out this last issue, I would just like a little
more feedback. So let me try to lay this out as a simple choice. (Scott
pls correct anything you think I'm not representing correctly!)
connectToServer currently has two forms, one with the annotated class,
the other with the ClientEndpointConfig instance.
These forms allow the spec to require (in the EE setting) that the
implementation use CDI to instantiate the endpoints, so the client
endpoints are automatically non-contextual managed beans, and so,
without any extra work on the part of the developer, they have the sort
of nice injectable properties that many of the other Java EE components
have out of the box.
However, for developers who don't care about this, and need to share
state between the websocket application and the client endpoint
instance, its clunky, as they'd have to use the
ClientEndpointConfig.getUserProperties() property bag for programmatic
endpoints, or do something funkier with a custom Configurator for
annotated endpoints. Which argues for the form of connectToServer that
takes endpoint instances created by the developer, not the implementation.
I feel that supporting the first form is very important, and would like
to support the second form. The only hesitation I have is the extra
complexity of more API and having to explain the difference. For
comparison, the Servlet API has both per instance and per class
registration, so if we add these methods, we're in ok company :)
I guess another reason for adding the instance based approach to what we
have is for developers who have their own injection frameworks. Is that
compelling to folks here as a reason ?
So,
A) Keep the API as is, don't add the per -instance connectToServer methods.
or
B) Pls add the new methods, they're useful and people can read the javadoc.
Thanks !
- Danny
On 2/27/13 6:17 PM, Scott Ferguson wrote:
> On 2/27/13 5:49 PM, Danny Coward wrote:
>> 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.
>
> thanks for the clarification.
>
> -- Scott
>
>>
>> - 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
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation