> Niclas Hedhman wrote: >> Looking from 10,000 feet, what is then the difference between an >> "object" residing in Context and one that can be looked up in the >> ServiceManager?? > > Currently, it is the purpose of the object. I understand where you are > coming from. For Avalon 5 whenever we get to that, I would like to have > one lookup manager--perhaps even a JNDI context that is passed in (no > InitialContext capabilities)--but that is the future. We have the > present Avalon 4 to support.
IMVHO it is a bad habit to expand on or extend a concept that is planned/considered to be removed. I would like to propose that the Context package is deprecated, and the context values are made available via the ServiceManager instead. That would also give the Component authors some reasonable time to adjust to the complete removal later. Aaron Farr wrote; > The difference is lifecycle and lifestyle management. > Objects from the ServiceManager are guaranteed to go > through the proper lifecycle and have proper lifestyle > management. You have no such promise for Context values. Are you saying is that "because Context values doesn't have a defined lifecycle, we must keep them"? Context values can be created as components but not the other way around, so...? If I don't declare any interfaces in the component, it could be a Context value, i.e. ContextValue is-kind-of Component, and I could basically create Components that behaves like the existing context values. Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
