avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@realityforge.org>
Subject Re: [SUMMARY] Context
Date Tue, 26 Nov 2002 11:19:06 GMT
On Tue, 26 Nov 2002 21:40, Nicola Ken Barozzi wrote:
> _Context_ and _Contextualizable_  are *the* way in which the Container
> can give the Component some *data*.

Thats not how it is used nor how it is described in javadocs. To extract some 
words from the javadocs

 * Each Container-Component relationship will also involve defining
 * a contract between two entities. This contract will specify the
 * services, settings and information that is supplied by the
 * Container to the Component.
 * The values placed in the context are runtime values that can
 * only be provided by the container. The Context should <b>NOT</b> be
 * used to retrieve configuration values or services that can be provided
 * by peer components.

So essentially it defines runtime values (data and services) that are only 
capable of being supplied by the container. There is no need to mix concerns 
between peer/user provided values and container provided values.

Examples of container provided services that should not be provided by peers;

     * A block can request that the application it resides in be
     * shut down. This method will schedule the blocks application
     * for shutdown. Note that this is just a request and the kernel
     * may or may not honour the request (by default the request will
     * be honored).
    void requestShutdown();

     * Retrieve a resource from the SAR file. The specified
     * name is relative the root of the archive. So you could
     * use it to retrieve a html page from within sar by loading
     * the resource named "data/main.html" or similar.
     * Names may be prefixed with '/' character.
     * @param name the name of resource
     * @return the InputStream for resource or null if no such resource
    InputStream getResourceAsStream( String name );

     * Retrieve the proxy for this object.
     * Each Block is referenced by other Blocks via their Proxy. When Phoenix
     * shuts down the Block, it can automatically invalidate the proxy. Thus
     * any attempt to call a method on a "dead"/shutdown object will result in
     * an {@link IllegalStateException}. This is desirable as it will
     * stop objects from using the Block when it is in an invalid state.
     * <p>The proxy also allows Phoenix to associate "Context" information 
     * the object. For instance, a Block may expect to run with a
     * specific ContextClassLoader set. However if this Block were to be 
     * to another component that processed the Block in a thread that did not
     * have the correct context information setup, then the Block could fail
     * to perform as expected. By passing the proxy instead, the correct 
     * information is maintained by Phoenix.</p>
     * <p>Note that only interfaces that the Block declares as offered 
     * will actually be implemented by the proxy.</p>
    Object getProxy();

     * This method is similar to {@link #getProxy()} except that it operates
     * on arbitrary objects. It will in effect proxy all interfaces that the
     * component supports.
     * <p>Proxying arbitrary objects is useful for the same reason it is 
     * to proxy the Block. Thus it is recomended that when needed you pass
     * Proxys of objects to minimize the chance of incorrect behaviour.</p>
     Object getProxy( Object other );

     * This method generates a Proxy of the specified object using the
     * specified interfaces. In other respects it is identical to
     * getProxy( Object other )
    Object getProxy( Object other, Class[] interfaces );


Peter Donald
Murphy's law - "Anything that can go wrong, will." 
(Actually, this is Finagle's law, which in itself 
shows that Finagle was right.)

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message