Darrell DeBoer wrote:
You lose an important difference. Service, provided as a result of component depedencies, are not regular objects - they are handled through a lifecycle, represent a version interface, are suplied by a version implementation componet, etc. A context entry on the otherhand is something native - an instance of java.io.File, a java.lang.String, a java.lang.ClassLoader, etc. These native artifacs are not services, they are native langauge resources that fall outside of the notion of a service per. se.On Sun, 24 Nov 2002 00:35, Stephen McConnell wrote:From another branch of this thread:
In every single one of the examples you have provided above, the(I've replied to this in-thread.) I believe this solution is superior to extending the concept of a Context.
extension of context is related to the exposure of a service. Take the
"forwardMail" example and image we want to create a component that is
complete and container agnostic. What we would do is declare that the
component in question has a dependency on a MailForwardingService. The
contract says nothing about where the service comes from (could be the
result of assembly, could be the result of a facility supplied by a
custom container). The point is that using *existing* Avalon Framework
contracts - this sort of dependency can be expressed providing we have a
consistent component model. Combine this with standard context entries
(avalon:home, avalon:work, etc) and the whole requirement for context
specialization disappears - or is at least pushed out into relatively
closed environments where component reuse outside of a particular
technical domain is of no interest.
If we can limit the use of "Context" to a very small set of standard entries, and use the regular service-dependency mechanism for anything that might be remotely container-specific, we avoid making this more complicated than it has to be.
To be honest, I'm not sure we'd lose much by ridding ourselves of Contextualizable altogether - maybe make Context just another service (the GenericUntypedHashMapThatMayJustHaveWhatYoureLookingForButWeCantGuaranteeIt service ;).
Context is good and effective for those little things.
Context becomes painful when extended to provide more than this.
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]>
