Berin Loritsch wrote:
J Aaron Farr wrote:
On Mon, 2003-07-21 at 21:30, Stephen McConnell wrote:
I'm not keen on shfting this outside of the @avalon namspace because its not different to a @avalon.dependency or @avalon.context - they all relate to lifecycle fulfilment.
Is the issue with @avalon namespace that it should be reserved for only those tags/features which every container supports? ie- Phoenix doesn't have lifecycle extensions yet therefore @avalon.stage should be @lifecycle.stage (or whatever)? Or is it because lifecycle extensions are part of excalibur and not framework?
Just trying to understand what and why we want to reserve the @avalon namespace for. I suppose this is more a question for Berin.
I want to let us allow for arbitrary meta-information which will be used for extension points. For example, support for Lifecycle Extensions as it is currently defined can be put into a container extensions (Appliance in Merlin speak), and that set of information would be available for that container extension.
That way we can easily expand upon the core of Avalon's features, and
easily add support for these lifecycle extensions uniformly accross all
containers. At least this is my current train of thought. Esp. since
we will have to track the @mx-*** management tags as a container extension
as well. If we define the mechanisms to do that, all is well.
Seems to be that we are talking about two different things that sound like the same thing. One subject concerns the @avalon.stage and @avalon.extension tags with respect to the appropriate namespace they they belong to. The second and distinctly different subject is the matter of supplementing meta-info.
I going to put forward some thoughts on the subject - and then end up contradicting myself - so be patient with me.
If we consider the first topic (stage and extension tags) - IMHO these belong inside the Avalon namespace because they are intrinsically part of the definition of a component type. This is irrespective of the support or non-support that a particular container has for lifecycle extensions. A non-supporting container must recognize that a component type has expectations that it cannot fulfill - and as such a well-behaved container must not attempt to deploy that component. In some respect stage and extension tags reflect the notion of deployment dependencies and deployment phase services (as distinct from the classic structural dependencies and service notions).
The second subject (meta-info extension) is not described in the meta-info model itself. Berin provided an example of a possible meta-info extension - namely jmx related meta associated with a particular component type. In an email yesterday Vinay also described requirements which I believe fall into the category of meta-info extension. If we take Vinay's example. He wants to include a bunch of "special" meta-info into a type definition so that he do a bunch of exiting stuff inside a custom appliance. This is pure container-side extension. I suggested to Vinay that he should using an attribute inside his component type definition as a tag from which his custom appliance could locate his domain specific meta data. A problem with this suggestion (that I think is issue Berin is playing with) is that there is now way in the current meta info model to declare to a container that a particular meta-info uses or is extended as a result of some additional domain meta-info.
In Vinay's use-case, if we assume that Vinay wants safe deployment across any container (note the word "safe" - not "successful"), then the process of loading meta-info has to be aware of meta-info-extension requirements. There are a couple of approaches here - extension via custom meta-info loaders, or extension via aggegation of meta-info extensions. I am strongly opposed to the idea of meta-info loader overloading on the grounds that this represents a potential security hole - however - I don't see a problem with meta-info-extension aggregation.
Consider the following type definition in which I have added the notion of <customizations/>.
<type>
<info>
<customizations>
<customizer id="mx" factory="org.somewhere.MyCustomizerFactory"/>
<customizer id="vinay" factory="org.vinay"/>
</cutomizations>
</info>
</type>In the above model, our standard (final) type loader can look at this information, locate a meta-info factory definition, and use that factory to create a meta-info supplement. Here is an example of the sort of interface that a customizer factory would need to implement:
public interface CustomizerReader
{
Serialized readCustomizer( final InputStream input )
throws Exception;
}Using the value "vinay" (as an example of a resource kind), the type builder can establish the input stream to "<classname>.vinay", and apply the input stream to the factory. The factory returns a serializable instance. The type builder can continue this process with other meta-info customizers (e.g "<classname>.mx"), resulting in the collection of customizers that supplements a type definition. This approach ensures that any meta-info customizer is serializable (which in turn ensures that the container can propagate customizers along with Type(s) as serialized objects). Naturally we would need to define a write-to-xml interface for this to all work properly (possibly included in an overall CustomizerFactory interface).
And now for the contradiction - I don't think we should do this. As I described to Vinay - I think we should hold off until we get more experience with the basic meta-info model.
Thoughts?
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]
