Re: Metainfo generation and access

Stephen McConnell Tue, 29 Jul 2003 05:13:21 -0700

Leo Sutic wrote:

From: Stephen McConnell [mailto:[EMAIL PROTECTED]

Leo Sutic wrote:

From: Berin Loritsch [mailto:[EMAIL PROTECTED]

In this case, Phoenix would be able to recognize the components as requiring functionality it can't deliver, and then refuse to deploy it. This addresses both Stephen's and my concerns.

Wait wait wait wait wait...

If a tag has to be explicitely recognized by all containers,

i.e. the
container must do this:
  if (tag.equals ("lifecycle")) {
      fail ("I don't support that tag.");
  }
instead of just defaulting:
  if (!supportedTags.contains (tag)) {
      fail ("I don't support that tag.");
  }
Then it should be in the avalon namespace.
Exactly.
But is it so?

I think this is even more of a problem than what the thread was about.
As it is now, each container has its own javadoc-tags to XML-descriptor
tool.
This is wrong, because each tool only looks at the tags of interest
to itself, so of course if a class has a tag that the generator
has never heard about it simply *cannot* warn or halt. For example,
if the tag @ejbType is encountered, what should the task do, unless
it has explicitely been told what to do?
Fail? Why? ejbType has *no* effect on avalon components.

Warn? Why? It has no effect?

Remain silent? How does it know that ejbType doesn't have any effect?

The point is that we at generation time *have no clue* about what tags are important and which aren't.
Even if the stage and extension tags were in the avalon namespace, if
the xml-descriptor generation task doesn't recognize them, it doesn't
matter if the container recognizes them.
The only solution I see is this:

1. Have a xdoclet task that converts javadoc tags to XML. All tags.
2. Save this xml descriptor next to the class file in the jar. For
   example, org/leo/MyComponent.class and org/leo/MyComponent.xml
3. Provide an API to access the XML descriptor. For example:
        Attributes getAttributes (Method m);
        Attributes getAttributes (Class c);
        Attributes getAttributes (Field f);
        Attributes attrs = getAttributes (componentClass);
        StageDescriptor sd = (StageDescriptor) attrs.getAttribute
("avalon.stage");
...
        // Check that all tags in the avalon namespace for this class
        // is supported
        Iterator iter = attrs.getKeys ("avalon").iterator ();
        while (iter.hasNext ()) assert (supportedTags.contains
(iter.next ()));
        // Check that all tags in the x-avalon namespace for this class
        // is supported
        Iterator iter = attrs.getKeys ("x-avalon").iterator ();
        while (iter.hasNext ()) assert (supportedXTags.contains
(iter.next ()));
This enables me to run *one* task to get the javadoc tags and their
information. Then the container gets to extract whatever tags it
cares about.

Don't think it would be workable. What currently happens in both Phoenix and Merlin is that a tag is written in and as a result of that read, other tags are assessed, leading to the buildup of a meta-info descriptor object. The descriptor is then written out in serialized or XML form. At this point you have a persistent meta-info representation. This same process can be applied to things such standard @mx tags, resulting in the generation of non-avalon descriptors using non-avalon tools.

The next step concerns recognition. When a container (or tool) is presented with a source component path (directory, jar, etc.) it can scan the contents for recognized resources. In the case of Phoenix it recognizes the .xinfo resource, in the case of Merlin it recognizes both Phoenix xinfo and a set of Merlin resources. What is not recognized is other resource types. For example, if we consider the above (an MBean descriptor for example) - how does a container know that something is required to read and process this resource? In the Merlin environment this is handled with extensions. The component in question can declare an extension and the extension can handle the processing of non-avalon information and do subsequent validation.

This approach works nicely, but there are limitations we have encountered. For example, Merlin includes a extended extension handler that provides the extension access to the management of the component, the complete meta-info and meta-data. For that information a completion solution is possible. This adaptation has not changed the definition of tags or even the meta-info model. Instead, a supplementary extension mechanism was introduced to more effectively handle the use-case.

This all works nicely although improvements can be made. One improvement I have been working on (the again does not impact tags and the meta-info model) is the separation of the "meta-model" from the managing appliance. This has the benefit of removing the ability for an extended extension to navigate. Instead of supply the extension with an appliance, we will be able to supply the extension with the meta-model.

Hope that helps.

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]

Re: Metainfo generation and access

Reply via email to