Leo Sutic wrote:
Brief summary and my own thoughts:
The Context is used as a means to provide data to the component.
The Avalon docs say that "The context is the interface through which the Component and it's Container communicate" but I think it has been shown that any "active" operations can be better handled as Services, accessible via a ServiceManager.
So, I'd like to specifically address the point of "what data".
My thoughts are this: The data is not a general Object-passing mechanism. That is, the type of data being passed is limited. Every container, when it deploys its components (be they servlets or maillets or whatever), sets up a small block of data for it. That block of data can be, for web-servlets the root URL for the servlet, activation time, or mail address for mailets. The block can also contain the class loader in containers that do classloader isolation.
Now, I'd say that the Context is the component's way of accessing that data block and nothing more.
Now, what do we do with a component that used to run in a container providing a ClassLoader in the context, that we're moving to a container that does not practice CL isolation (and thus has no ClassLoader in the context)? Possibilities:
1) Tough luck.
2) Define a minimum set of context entries that all containers must support.
I vote -0 for (1) and +1 for (2).
I would suggest that we do this with a minimalist approach. I.e. lots of emphasis on the word *minimum*. My proposal for the minimum set is as follows:
key class description
avalon:work File The working directory assigned to a component.
avalon:name String The name assigned to the component by a container
(typically used by a component in logging and
error reporting).
Both these standard keys could be supported by standard convinience interfaces:
interface WorkingDirectoryProvider
{
File getWorkingDirectory();
}
interface NameProvider
{
String getName();
}
For the situation where we have a component that requires a context entry that isn't provided by the container, and that didn't make it into the minimum set of context entries, I'm +1 on (1). As long as we make it crystal clear what context entries are container specific and what are portable we shouldn't have any problem.
I agree in principal (some comments on the working but its not important).
Merlin:
I know that Merlin provides a generalized way of adding context entries via a String->Object conversion facility, meaning that in Merlin, the Context can be adapted so that even if Merlin can't provide the required context entries, the applicaion assembler can explicitely add them and thus force a component to run. I suggest this be kept as a container-specific extension, and not be made a requirement for all containers.
Now to some serious issues:
Merlin can sort-of fake the context due to the String->Object conversion outlined above. However, I have a proposal where one used interfaces to describe the context one would want. Stephen, you said you didn't like the interfaces-only approach, but you never really detailed what the issues were. Am I right in saying that if I could provide you with a way to be able to fake a context based on interfaces just as you can now fake one based on key/value-pairs, you would not have any objections?
Short answer - no objections at all.
Merlin has a mechanism whereby "standard" context entries can be manipulated to form new context solutions. This involves:
* Importing standard context values from a container to a context manager
* Creating new objects based on imported and constructed objects
This is combined with the usage of a standard pattern of context implementation creation (basically the creation of a Constructor that follows the DefaultContext pattern). This enables component authors to solve problems like dealing with BlockContext.
I consider this as one context management strategy. The objective within Merlin is to enable multiple plug-in strategies to be used within Merlin. The framework for this is not complete at this stage, however, if you make the assumption that the component management provider is a classic component (just like an extension handler), then Merlin will be able to apply that component as a context strategy solution replacing and/or supplementing the default Merlin context management solution for a particular container within the containment hierarchy.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
