Save This Page
Home » spring-framework-2.5.5-with-dependencies » org.springframework » beans » factory » config » [javadoc | source]
org.springframework.beans.factory.config
public interface: Scope [javadoc | source]

All Known Implementing Classes:
    SessionScope, AbstractRequestAttributesScope, RequestScope

Strategy interface used by a ConfigurableBeanFactory , representing a target scope to hold bean instances in. This allows for extending the BeanFactory's standard scopes "singleton" and "prototype" with custom further scopes, registered for a specific key .

org.springframework.context.ApplicationContext implementations such as a org.springframework.web.context.WebApplicationContext may register additional standard scopes specific to their environment, e.g. "request" and "session" , based on this Scope SPI.

Even if its primary use is for extended scopes in a web environment, this SPI is completely generic: It provides the ability to get and put objects from any underlying storage mechanism, such as an HTTP session or a custom conversation mechanism. The name passed into this class's get and remove methods will identify the target object in the current scope.

Scope implementations are expected to be thread-safe. One Scope instance can be used with multiple bean factories at the same time, if desired (unless it explicitly wants to be aware of the containing BeanFactory), with any number of threads accessing the Scope concurrently from any number of factories.

Method from org.springframework.beans.factory.config.Scope Summary:
get,   getConversationId,   registerDestructionCallback,   remove
Method from org.springframework.beans.factory.config.Scope Detail:
 public Object get(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.

    This is the central operation of a Scope, and the only operation
that is absolutely required.
 public String getConversationId()
    Return the conversation ID for the current underlying scope, if any.

    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.
 public  void registerDestructionCallback(String name,
    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).

    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 #remove(String) 
method, any registered destruction callback should be removed as well,
assuming that the removed object will be reused or manually destroyed.
 public Object remove(String name)
    Remove the object with the given 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.