public class SimpSessionScope extends java.lang.Object implements Scope
Scope
implementation exposing the attributes of a SiMP session
(e.g. WebSocket session).
Relies on a thread-bound SimpAttributes
instance exported by
SimpAnnotationMethodMessageHandler
.
Constructor and Description |
---|
SimpSessionScope() |
Modifier and Type | Method and Description |
---|---|
java.lang.Object |
get(java.lang.String name,
ObjectFactory<?> objectFactory)
Return the object with the given name from the underlying scope,
creating it
if not found in the underlying storage mechanism. |
java.lang.String |
getConversationId()
Return the conversation ID for the current underlying scope, if any.
|
void |
registerDestructionCallback(java.lang.String name,
java.lang.Runnable callback)
Register a callback to be executed on destruction of the specified
object in the scope (or at destruction of the entire scope, if the
scope does not destroy individual objects but rather only terminates
in its entirety).
|
java.lang.Object |
remove(java.lang.String name)
Remove the object with the given
name from the underlying scope. |
java.lang.Object |
resolveContextualObject(java.lang.String key)
Resolve the contextual object for the given key, if any.
|
public java.lang.Object get(java.lang.String name, ObjectFactory<?> objectFactory)
Scope
creating it
if not found in the underlying storage mechanism.
This is the central operation of a Scope, and the only operation that is absolutely required.
get
in interface Scope
name
- the name of the object to retrieveobjectFactory
- the ObjectFactory
to use to create the scoped
object if it is not present in the underlying storage mechanismnull
)public java.lang.Object remove(java.lang.String name)
Scope
name
from the underlying scope.
Returns null
if no object was found; otherwise
returns the removed Object
.
Note that an implementation should also remove a registered destruction callback for the specified object, if any. It does, however, not need to execute a registered destruction callback in this case, since the object will be destroyed by the caller (if appropriate).
Note: This is an optional operation. Implementations may throw
UnsupportedOperationException
if they do not support explicitly
removing an object.
remove
in interface Scope
name
- the name of the object to removenull
if no object was presentScope.registerDestructionCallback(java.lang.String, java.lang.Runnable)
public void registerDestructionCallback(java.lang.String name, java.lang.Runnable callback)
Scope
Note: This is an optional operation. This method will only be called for scoped beans with actual destruction configuration (DisposableBean, destroy-method, DestructionAwareBeanPostProcessor). Implementations should do their best to execute a given callback at the appropriate time. If such a callback is not supported by the underlying runtime environment at all, the callback must be ignored and a corresponding warning should be logged.
Note that 'destruction' refers to to automatic destruction of
the object as part of the scope's own lifecycle, not to the individual
scoped object having been explicitly removed by the application.
If a scoped object gets removed via this facade's Scope.remove(String)
method, any registered destruction callback should be removed as well,
assuming that the removed object will be reused or manually destroyed.
registerDestructionCallback
in interface Scope
name
- the name of the object to execute the destruction callback forcallback
- the destruction callback to be executed.
Note that the passed-in Runnable will never throw an exception,
so it can safely be executed without an enclosing try-catch block.
Furthermore, the Runnable will usually be serializable, provided
that its target object is serializable as well.DisposableBean
,
AbstractBeanDefinition.getDestroyMethodName()
,
DestructionAwareBeanPostProcessor
public java.lang.Object resolveContextualObject(java.lang.String key)
Scope
resolveContextualObject
in interface Scope
key
- the contextual keynull
if none foundpublic java.lang.String getConversationId()
Scope
The exact meaning of the conversation ID depends on the underlying
storage mechanism. In the case of session-scoped objects, the
conversation ID would typically be equal to (or derived from) the
session ID
; in the
case of a custom conversation that sits within the overall session,
the specific ID for the current conversation would be appropriate.
Note: This is an optional operation. It is perfectly valid to
return null
in an implementation of this method if the
underlying storage mechanism has no obvious candidate for such an ID.
getConversationId
in interface Scope
null
if there is no
conversation ID for the current scope