On 1/9/13 11:04 AM, Arun Gupta wrote:
> Danny,
>
>> On 1/8/13 2:12 PM, Arun Gupta wrote:
>>> How do you expect a typical implementation of
>>> Set<Class>
>>> ServerApplicationConfiguration.getAnnotatedEndpointClasses(Set<Class>)
>>> to look like ?
>>
>>
>> Something like:-
>>
>> public Set<Class>
>> ServerApplicationConfiguration.getAnnotatedEndpointClasses(Set<Class>
>> scannedOnes) {
>> Set onesIWantToDeploy = new HashSet();
>> for (Class next : scannedOnes) {
>> if (doIReallyWantThisOneAfterAll(next)) {
>> onesIWantToDeploy.add(next);
>> }
>> }
>> return onesIWantToDeploy;
>> }
>>
>>
> I assume this would be read once at deployment time and so the list of
> WebSocket endpoints will be defined at that time ? What kind of
> information is available in doIReallyWantThisOneAfterAll(next) to make
> a decision ?
>
> What would be some typical criteria ?
Hey Arun,
One easy one might be you are trying to isolate a couple websocket
endpoints in a WAR file that has dozens, perhaps to debug a problem. So
you just match by classname against a list of ones you want.
The background to this was the desire to have an easy and efficient
scheme for deploying everything in the WAR file. That's the case when
you just put everything in the WAR file and don't provide any
ApplicationConfiguration implementations.
Then, we wanted to have a scheme that could deal with WARs what might
contain library files containing 'other people's' websocket libraries,
of which you only want to deploy a few. Then you want to filter the ones
you don't want out (by classname) without having to repackage everything.
The byproduct is that since you can turn off scanning using the
absolute-order element in the web.xml, you have another dimension of
control to turn off scanning of whole JAR files in the WAR file.
>>
>>>
>>> Seems like the parameter will already contain the list of classes
>>> annotated with @WebSocketEndpoint ?
>>
>> Yes, they are the result of the scan for annotated endpoints.
>>>
>>> Is the expectation that interface-driven endpoints will be added to
>>> this set and returned back ?
>> No, they are scanned for separately, and passed into
>> getEndpointConfigurationClasses(), or more precisely, their endpoint
>> configurations are scanned for and passed into that method.
> For an interface-driven endpoint, at least two classes are required ?
>
> - Endpoint class
> - ServerEndpointConfiguration
To deploy the programmatic endpoints, the container will look for
classes that implement ServerEndpointConfiguration to find them.
Its a little heavywieght to do it like this because 'plain' Endpoint
implementations will need to provide a class that implements
ServerEndpointConfiguration so that the scan picks them up. We'll try
and streamline this (
http://java.net/jira/browse/WEBSOCKET_SPEC-118)
To deploy annotated endpoints, the container looks for classes annotated
with @WebSocketEndpoint.
So developers/deployers can filter the scan results to get the list of
endpoints to deploy, the container will look for classes that implement
ServerApplicationConfiguration.
>
> And possibly a third ?
>
> - ServerApplicationConfiguration
>>>
>>> What if I do not include @WebSocketEndpoint in the list ? Are those
>>> endpoints then not deployed by the server ?
>> Correct, the ones you return out of these methods are deployed, which
>> may not be all of them.
>>
>>>
>>> Is there a mechanism to provide configuration across all the
>>> endpoints - annotation or interface-driven ?
>>
>> What kind of configuration ? If you want some kind of global thing
>> they all hook up to, then you can subclass/implement your own
>> *Configuration class with a getGlobalThing() method on it if you
>> like, except for the annotated client case (see last email).
> If I want to hook up a set of encoder/decoder(s) to all the WebSocket
> endpoints (annotated and interface-driven), is that not possible today ?
Yes, just list them in the config/on the @WebSocketEndpoint annotation
for all the endpoints you want them for.
The configuration I thought you meant was some kind of application state
you want to share across multiple endpoints. This is the kind of thing
you can do by providing your own *Configuration implementation objects
that carry things like database connections that you can then access
from multiple endpoints.
- Danny
>
> Arun
>>
>> HTH,
>>
>> - Danny
>>>
>>> Arun
>>>
>>
>>
>> --
>> <http://www.oracle.com> *Danny Coward *
>> Java EE
>> Oracle Corporation
>>
>
> --
> http://twitter.com/arungupta
> http://blogs.oracle.com/arungupta
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation