Noel J. Bergman wrote:
It's not an issue - this is simply a component implementation - and if that implentation does something worg, then the container has to act to rectify the situation (whatever the particular status of the component). The container does not care about JNDI - it only cares about specific states of the components it is managing + the components that are depedent on that component. If that target component fuctions within the guidlines of the A4.1 contract then fine - otherwise its a case of handling damage control (which is a semi-complex exercise).I (as spokesperson for Merlin) can gaurantee you that the objectWell, I'm not a big fan of such dependency upon external configuration
provided to you will be castable to you requested interface and
that it will be supplid with the requested keys fully populated
and that each key value will be castable to the requested interface.
files, but that's a moot point. You can do that in the context (small c) of
current Avalon containers and conditions.
However, we've already seen one developer wanting to expand Avalon to use
JINI, for example. Any component can ask for any other component at any
time in a dynamically populated environment. How do you expect to make JINI
compliant, or any other dynamically populated environment? I understand
that you don't expect to be there before AV5.
On the subject of the seperation of a single source from meta-info .. yes I agree that its not perfect, but I also think this is oniy a question of build tools. Today, I'm not convinced that the meta API is totally what we want and as such I'm not about to ivest time into those tools - it much more production to get the meta rights - then make the code/meta synchronization an automatic process.
One step at a time ....
:-)
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]>
