Purpose and use of Context (was: Re: reduction ad unum)

[Leo Sutic]

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).

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.


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?

/LS


--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>