On Mon, 2002-11-25 at 13:49, 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.
well put, I totally agree, sums it all up right there. > 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. yep, where I should say we should not require something of containers outside of the avalon project, just make it dead easy to do it the recommended way ;D some relevant stuff already going in this direction: http://jakarta.apache.org/avalon/excalibur/info/context.html http://jakarta.apache.org/avalon/excalibur/meta/context.html http://jakarta.apache.org/avalon/phoenix/api/org/apache/avalon/phoenix/interfaces/ApplicationContext.html http://jakarta.apache.org/avalon/phoenix/api/org/apache/avalon/phoenix/BlockContext.html we actually were at a point where we had already been over the best way to format the lookup string back in august, I think; can't find the docs right now. Regardless, a useful pattern is to store the lookup strings inside something like org.apache.avalon.info.CommonContextKeys.class, so it doesn't matter that much. cheers, - Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
