On 11/7/12 7:22 PM, Scott Ferguson wrote:
> On 11/7/12 5:59 PM, Danny Coward wrote:
>> Hello experts,
>>
>> Close students of the EDR spec will see that this is how the
>> application is bootstrapped:-
>>
>> A) In the web container, POJOs and programmatic endpoints are
>> packaged in the WAR
>> i) The implementation scans the WAR for annotated POJOs and deploys
>> them when the WAR is deployed
>> ii) For programmatic endpoints, the application developer has to
>> bootstrap the application 'by hand': by configuring an entry point
>> (like ServletContainerInitializer), and using the API
>> ContainerProvider.getServerContainer().publishServer(endpoint,
>> endpointconfiguration).
>>
>> B) In the standalone cases: standalone server, and standalone client,
>> the developer has to bootstrap the application in main() using
>> ContainerProvider.getServerContainer() or
>> ContainerProvider.getClientContainer() to get the appropriate
>> reference to the web socket container, from which he can
>> publishServer() or connectToServer().
>>
>> I'd propose a couple things to improve this, both as a convenience
>> for developers, and to unhook the API-implementation dependency
>> implied by the ContainerProvider API class:-
>>
>> 1) Require the websocket enabled web container scan for programmatic
>> endpoints in the WAR file and deploy them on startup. This would
>> require an API change to allow the Endpoint to supply its own
>> Configuration object: specifically add public EndpointConfiguration
>> getEndpointConfiguration() to Endpoint.
>
> I'm not sure I understand the difference between (1) and (A.i). Is (1)
> a similar WAR scanning to (A.i) but looking for "extends Endpoint"
> instead of "@WebSocketEndpoint"?
>
> I have a counter-proposal :) It may be a bit too radical.
>
> Suppose we support only the POJO model and remove
> Endpoint/MessageHandler entirely. When an application calls
> ClientContainer.connectToServer or ServerContainer.publishServer, it
> passes a POJO class (or instance) that's introspected for the annotations.
>
> The advantage is that it unifies endpoint to one programming model
> (for example it avoids the need to scan for Endpoint and simplifies
> the spec document).
>
> The disadvantage is that it seems radical to me. I'm not sure why I
> think that though.
Earlier, I filed a similar issue for this:
http://java.net/jira/browse/WEBSOCKET_SPEC-51
Jitu