You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/07/29 13:40:11 UTC
Metainfo generation and access (was: RE: [ANTI-VOTE] Lifecycle Extension Tags)
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic wrote:
>
> >
> >
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>
> >>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.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Metainfo generation and access
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic wrote:
>
> >>From: Stephen McConnell [mailto:mcconnell@apache.org]
> >>
> >>Don't think it would be workable.
> >>
> >I think it is, since that's the way attributes work in .Net.
>
> Viable when a meta-info structure in included in the JRE.
> I.e. a common meta-info access API. This is slanted for JRE
> 1.5 isn't it?.
Yes, but what would keep us from rolling our own until then?
Especially when that would help with a current problem.
If all containers have a common metainfo access API, then
this reduces to a naming issue, which is a non-issue.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Metainfo generation and access
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Don't think it would be workable.
>>
>>
>
>I think it is, since that's the way attributes work in .Net.
>
>
Viable when a meta-info structure in included in the JRE.
I.e. a common meta-info access API. This is slanted for JRE 1.5 isn't it?.
Stephen.
>>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.
>>
>>
>
>I suspected that.
>
>That, unfortunately, is a problem, as this is what makes a simple
>name change into a big deal.
>
>/LS
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Metainfo generation and access
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Don't think it would be workable.
I think it is, since that's the way attributes work in .Net.
> 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.
I suspected that.
That, unfortunately, is a problem, as this is what makes a simple
name change into a big deal.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Metainfo generation and access
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Leo Sutic wrote:
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>>
>>>>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:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org