Leo Simons wrote:
Farr, Aaron wrote:
Also, not to start a flame war or anything, but isn't 'avalon.dependency'
just as much a 'validation' issue as context, logging, and configuration
tags? I mean, it's just the container validating that such services exist
and allowing the component to access them. I don't see the difference
between this and say 'context'. But perhaps I'm wrong.
the thing is, how to do configuration validation is clear. You have an XML file, you can write a DTD or a relaxng schema or something like that and have the container apply it.
How to do dependency validation is also clear. We have several years of experience developing the composition part of the container-component contract. All we want to do here is to verify our composition graph is not cyclic, and to do that up front you need to specify that graph up front, which you can do intuitively by the use of attributes.
How to do context and logging validation is less clear. The only place where something like that is supported is merlin, and there it has only recently been put to the test by various people.
Also, the need for context and logging validation is less clear. That's why this needs all the fleshing out being done :D
What's not clear?
User's like castable context objects - just go and ask a few Phoenix users - doing m_context.getWorkingDirectory() is preferred to (File) m_context.get("whatever-the-key-is) and associated exception handling. Now, not all containers are created equal - so when a container deploys a component - it kind of risky because components can place a bunch of different requirements on a container. Now, if your a container - your probably saying to yourself, it would be nice if I could validate this component and make sure its not asking for anything I can't handle. This means that a container has to ask the right questions. One of those questions is "listen to me you dirty little component - I don't supose your one of those nasty ones that actually want to cast a context object, are you? And the component could answer "umm, zutt, .... yes!". With this information, our friendly container can kicks the component out of the equation and falls back to its "well-known dependency validation" with full knowlege that the dirty little component is out of the loop.
The other approach is to develop containers using STV.
Steve.
cheers,
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
