container managed injection features are not available to WebSocket endpoints which override the container implemented initialization (using theServerEndpointConfig.Configurator
)
Important: Please note that support for EJB annotations on WebSocket endpoints is not a standard (specification mandated) feature
@Singleton
ServerEndpointConfig.Configurator
(override the getEndpointInstance
to be specific and return the same instance). As mentioned in the Configuration chapter, this means that you might have to sacrifice some of the (Java EE) platform related services like dependency injection@Singleton
@Singleton
, all the clients will interact with one server endpoint instance. Here is a quick summary of how the EJB as well as WebSocket threading semantics are appliedSingleton
bean default approach (WRITE lock) ensures single threaded access across all connected clientsThe above mentioned semantics are with respect to ALL the WebSocket clients. From the point of view of a single client, the default strategy of one thread at a time, per endpoint instance per client continues to apply (more in the Concurrency chapter)
@Stateful
@Stateful
EJB instance per WebSocket client - this is in tune with the default behavior outlined by the WebSocket specification. Things would get interesting from a state management perspectiveStateful
beans can be leveraged if needed (be careful about not storing references to non java.io.Serializable
objects)javax.websocket.Session
is not Serializable
), it might be possible to implement a highly availabile (HA) setup for WebSocket applicationsuserId
and (chat) history
are user specific state which can be passivated, restored and replicated (across JVMs)Session
is marked transient
since we do not intend to serialize it to disk not over network (other JVMs in cluster)@Stateless
@Stateless
style endpoints can prove to be useful as well. Here are some of the noteworthy pointsSession
MessageDriven
) Stateless
, Stateful
and Singleton
can be injected into WebSocket endpoints. A good strategy would be to implement core business logic using EJBs which can be then invoked from within WebSocket endpoint lifecycle (callback) methods@Stateful
EJBStateful
EJB instance, which makes it an ideal candidate for storing client specific state. It offers advanced semantics as compared to simple java.util.Map
interface exposed by getUserProperties
method in javax.websocket.Session
)Tip: Implement a@Remove
annotated method in theStateful
EJB and call it from the@OnClose
callback method. This will ensure that the EJB is removed from the memory immediately rather than depending upon@StatefulTimeout
configuration​
@Stateless
and @Singleton
EJBs@Stateless
and @Singleton
EJBs can also be injected seamlessly. All the EJB features like transactions, simpler concurrency model, lifecycle management etc. can be leveraged@Stateless
@Singleton
@Stateful
beans.xml (in WEB-INF) is required in order to leverage Dependency Injection support
@Interceptors
annotation. You should employ the annotation for the type of interceptor i.e. @AroundInvoke
, @AroundConstruct
etc.@javax.inject.Inject
can be used (on constructor, method, field) to inject CDI managed beansThe CDI based interceptor works for EJB based WebSocket endpoints as well
@Inject
@EJB