Niclas Hedhman wrote:
Only if your context entry has a null construcor. How are you going to
diferrentiate between the establishment of a service and the creation of
a File instance? If context were removed, we would be forced to declare
factories for any "non-component" and that's not an attractive
proposition.
Well, from the User Components point of view, it is completely irrelevant of "How" the entry ended up in the ServiceManager's lookup, the container could very well have a set of hardcoded entries, just like the hardcoded entries in the Context today. But then I don't get the dependency checks I am after. I probably would like to see that the entries being exposed for dependency resoloution at assembly.
By moving the Context entries to the ServiceManager, then if a particular container didn't expose a required value, one could adopt a it to support the missing entries that components are looking for, by assembly declarations.
I hate this subject because I keep changing my mind!
OK - so I thought about this some more and I agree with what your saying in that "entries" (context or service) could be presented to a component using a single interface (Contextualizable, Serviceable, or something similar). Let's assuming we use contextualizable for the moment - the impact would be that instead of declaring <context/> + <services/> we could declare something like:
<type>
<info>
<name>DemoType</name>
</info>
<context>
<entry key="urn:avalon:name" alias="name"/>
<entry key="urn:avalon:partition.name"/>
<entry key="keystore" type="java.security.KeyStore"/>
<entry key="authority" type="org.omg.pki.RegistrationAuthority"
version="2.1"/>
<entry key="time" type="java.util.Data" volatile="true"/>
</context>
</type>So far so good. The component author is not concerned with "how" an entry is established and all of the entries are simply statements of dependencies that the component type has.
When a container looks at the above list is will resolve the "urn:avalon:*" entries using its internal standard entry set. That leaves us with keystore, authority and time. For each of these, the container knows if a service (a.k.a component) is available to handle the type. In which case the container is probably going to recognize the RA as a registered service, leaving "keystore" and "time" as custom context entries that need to be constructed (i.e. the container has to pull in some meta-data and process some directives).
If you make the assumption that any entry *must* fall into one of the following three categories, then I think its possible:
1. a standard context entry 2. a registered service type 3. a custom context type (i.e. declared in meta-data)
Umm, interesting thing is that this would only require one small addition to the meta-info model, namely the addition of the version attribute on a context entry. Legacy A4 support could be provided by provided my mapping the generic context as the provider to both serviceable and contextualizable.
Cheers, Steve.
--
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]
