avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [RT] Standardizing Meta Info
Date Mon, 07 Jul 2003 22:37:45 GMT

The big answer ....

Berin Loritsch wrote:

> We have a start with the AMTAGS proposal, so we do have a vested 
> interest in
> completing the job of Meta Info representation.


> The purpose of this Random
> Thought (RT) is to standardize the persistence of the Meta 
> Information, or
> how it is stored in the JAR files.

Good timing - have been working on only this for the last few days.

> All three of the Avalon containers have different mechanisms for doing 
> this,
> and it would be really great to standardize on one. So far, Merlin has 
> the
> most expressive format, so we might want to use that format to handle the
> integration. In fact, we might want to adapt that whole library (the 
> Merlin
> Meta) library to meet the needs of all the containers. 

I would suggest we establish the following Avalon projects:

avalon/info-spi ........... the immutable meta-info classes
avalon/info ............... builders, writers and validators
avalon/info-tools ......... generators and other meta-info tools

The avalon/info-spi would correspond largely with the existing info 
package in Merlin meta-spi. The avalon/info package would correspond to 
the Merlin meta info.builder package plus some reorganization of the 
writer classes in Merlin meta-tools. The avalon/info-tools package would 
cover the javadoc tools specifically addressing javadoc to meta-info 
generation (but there are other tools that can go here - component 
report generation, meta-info doclets, ant tasks and maven plugins, etc.).

The significant point here is that I'm proposing the separation of the 
meta-info (descriptors) from the meta-data (directives). I imagine a 
future in which we introduce avalon/data-spi, avalon/data, and 
avalon/data-tools as the standard framework for writing deployment 

> Quick Note:
> The use of @avalon.meta.XXX should be discouraged. @avalon.XXX is the
> namespace for Avalon related meta information, and the ".meta." for each
> and every tag is not only unnecessary, it is very repetitive. All Avalon
> tags should be marked by @avalon.XXX only. Those tags should be recorded
> in the AMTAGS proposal.


Leo did a good analysis on the current implementation of the avalon.meta 
tags. The majority of the issues raised have already been addressed - 
but there is still some more hashing out stuff that needs to be done - 
but more on that as we break out the details.

> Also, a point of contention in the past is one of versioning in the 
> service
> and implementation types. After more thought on the matter, I am inclined
> to agree it is useful information that can be used to validate contract
> compatibility with the component. It should not be absolutely required,
> but used if it exists.

There are two versioning aspects in the existing meta-info model - 
service versions and component implementation versions. Service versions 
are used and respected in the Merlin and Phoenix platforms. Component 
type versioning is provided in Merlin but is not used computationally - 
i.e. it is considered as management information. As far as the service 
versioning is concerned - the current implementation defaults to 
"1.0"which is a bad thing. Basically we need to default to null and make 
sure that we are clear about what null implies when doing a version 
check. My position is that null should result in the a "undefined" 
version in which case any service version would map. This would be 
consistent with Fortress but would need some adjustments in Merlin to 
sync with the semantics.

> Back to the subject at hand. I want to be able to quickly and easily 
> adapt an
> existing library to the task at hand. This will obviate the need for 
> three
> different ways of generating meta information for Avalon components.
> Currently we have two XML formats and one property based format. The 
> Fortress
> property based format should be considered a quick and dirty hack for 
> persisting
> meta information. However, there are a couple things we should 
> discuss, namely
> the use of the JDK 1.3 services approach well documented in the JAR 
> file docs
> by SUN, and the extension of that to list the services.
> Merlin and Phoenix both use the META-INF/MANIFEST.MF format to 
> identify the
> components. In the end this might be the best approach as it 
> identifies the
> types instead of the services as primary which seems to be more common.
> More thoughts on this would be welcome. 

The usage of manifest meta info in Phoenix and Merlin is limited to the 
support for the Sun Optional Extensions Specification. This is different 
level or granularity to components. Phoenix discovers components based o 
the declarations in its assembly file whereas Merlin scans jar files for 
meta-info. The only role that manifest info plays is to facilitate the 
automation of classpath creation based on jar file dependency statements 
- but this is relatively independent of the meta question.

> XML file format differences can be easily accounted for by using a simple
> transformation to convert one XML format to another. Not to mention that
> Merlin Meta does read Phoenix meta info natively. That is a good thing. 

The Merlin approach is to use the Type object as the transformation 
source. For example, when generating an XML source from javadoc tags, 
Melin uses the javadoc tags to create a Type instance then writes that 
instance out to a particular target format. Current input and output 
mappings look like:

@avalon.meta | |
XML Type xinfo | | XML Type (xinf)
Serial Type |---> Type ----> | Serial Type
Phoenix BlockInfo | |

> The main question is how easy is it to extend Merlin Meta? If the data 
> model
> is too specific, then we can run into a problem. If the data model is 
> nice and
> generic, then all is well.

 From experience this is not such a simple question. The flexibility in 
the current model is achieved through an ability to supplement a type 
description with attributes at just about any level. This is totally 
sufficient for even the most strange and bizarre extensions. The 
limitations concern the introduction of a new formalism - for example, 
lifecycle extensions required the addition of new state, which in turn 
requires explicit version management of the serializable implementation. 
I sure that there is some additional smart stuff that can be 
incorporated to better handle multiple version of serialized content, 
but I'm not so up-to-spped on this area.

The very big plus about the current model is that it is serializable. 
This means that the meta-info model can be passed across the wire 
between management tools and deployment engines (containers). The same 
things applies to meta-data. Combines serializable meta-info with 
serializable meta-data means we can arrive at a serializable meta-model. 
This has really big implications with respect to distributed management 
(just for reference - it’s the serializable meta-data and meta-model 
management that I've been working on most of last week).

> Stephen has a decent outline as to the types that are essential to track.
> If we need to expand on that we can do so as the need arrises. Are there
> any deficiencies where Merlin cannot track Phoenix attributes? 

There are 2 deficiencies.

1. declaration of a configuration schema (easily addressed
and required for full Phoenix support)
2. declaration of management access points (not so easy, but
potentially separable from the type definition - a more
complex subject that deserves another thread)

> Fortress
> has a common subset that is very limited.

Bernard is already looking into stuff in this area.

> The important thing to do in this case is to ensure that the meta info is
> collected the same way. I have a feeling that if we remove the *.meta.*
> from the Merlin collection mechanism things will be a bit easier to 
> integrate.
> Any thoughts on this? 

Removing the *.meta will result in something reasonably close to a full 
spec. I have updated most of the tags to following the "standard" 
pattern - but I need to check through things to make sure its complete. 
I also need to go back over Leo's email and see how things stand.

That’s all for tonight!

Cheers, Steve.


Stephen J. McConnell

Sent via James running under Merlin as an NT service.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message