[WEBSOCKET_SPEC-7] Boostrapping websocket containers in web container and standalone Created: 21/Sep/12  Updated: 17/Nov/12  Due: 09/Nov/12  Resolved: 17/Nov/12

Status: Resolved
Project: websocket-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dannycoward Assignee: dannycoward
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: v008

 Description   

For now the API has a ContainerProvider class that can use the service loader mechanism to load
different implementations of the Client and Server containers. This will be ok for the Java SE client
API, but probably not for Java EE.

We will explore other mechanisms in the Java EE case. Perhaps making the ServerContainer a CDI managed bean that can
be injected into developer code, perhaps into a ServletContext initializer, for example. Or an annotation that the web
container must scan for that indicates that a given class implementing one of the Container interfaces must be loaded at
startup.



 Comments   
Comment by dannycoward [ 12/Nov/12 ]

Some notes on client-side and server-side deplotment

Server Side
automatic POJO scanning
No scan for Endpointsubclass, programmtically deploy
deploy method should work for POJO

Client Side
no scan, programmtic deployment (client needs to control when to connect)
programmtic POJO deployment.

Comment by dannycoward [ 17/Nov/12 ]

We have added the appropriate client deployment API for POJOs and Endpoints and adjusted the server API for deployment. The spec document has been updated for the WAR scanning for POJOs.

Generated at Sat Feb 06 00:26:47 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.