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
with
* the object. For instance, a Block may expect to run with a
* specific ContextClassLoader set. However if this Block were to be
passed
* 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
context
* information is maintained by Phoenix.</p>
*
* <p>Note that only interfaces that the Block declares as offered
services
* 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
useful
* 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 );
--
Cheers,
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
