avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Ist it just me? (was Re: [Meta] Confused by the terms)
Date Thu, 18 Mar 2004 14:40:06 GMT


> From: news [mailto:news@sea.gmane.org] On Behalf Of Berin Loritsch
> 
> Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
> 
> > -----Mensagem original-----
> > De: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > 
> > 
> >>Now, we could argue about the correct terms for months but the term 
> >>"type" is imho misleading here. If a type exposes all features of a 
> >>component why is it called a type and not component?
> > 
> > 
> > Its a TypeDescriptor. Something like "for class X there are these 
> > dependencies, these custom lifecycles" and so on.
> 
> Here in lies one of the fundamental problems I have with the 
> Meta package.  If there is this much discussion about it with 
> people who are Avalon veterans, then something is seriously 
> wrong.  It is too complex, and introduces too many new 
> concepts that we haven't bought off on.
> 
> This is a "code smell" or at least a "design smell".

I think there are parts of Meta that we have already accepted,
and parts we haven't accepted.

What we have accepted, at least partly, is that we should have
*something* that is "java.lang.reflect for Avalon". I.e. some
way to access Avalon-specific metadata about components, interfaces 
etc.

We also have sort-of consensus what should go into that metadata.
For example, we want to be able to define:

 + Dependencies

 + Versions

 + Context requirements

I think we have consensus on the above.

What we don't have consensus on is the way that data is

 + Specified in the source code / extra files

 + collected during the build process

 + accessed at runtime

and this is where the conflicts are.

Otherwise, we're pretty much in agreement. For example:

 Avalon Meta:

  @avalon.security.permission class="java.util.PropertyPermission" 
                              name="java.version" actions="read,write"

 Commons-Attributes:

  @@PermissionDescriptor(java.util.PropertyPermission.class, 
                         "java.version", 
                         new String[]{ "read", "write" })

However, the way the metadata is specified, collected and accessed
differs vastly between Avalon Meta and Commons Attributes.

So what should be kept from Avalon Meta? 

 + The model. OK, maybe we should rename Type to Component, and lose
   the -Descriptor ending. I mean, its java.lang.Class and not 
   java.lang.ClassDescriptor, after all. But I think the model
   captures a lot of good stuff.

What should we drop? (Note: "drop in a backwards-compatible way" - i.e.
not abandon our users.)

 + The XML format.

The XML format should be dropped - if we have an API to access it, it 
shouldn't matter what the underlying format is.

  Class myComponentClass = ...;
  Type t = new Type (myComponentClass);

Should be all.

 + The current collection process.

The current builder only recognizes tags it is programmed to 
recognize. This is a problem, since it means you have to modify
the build process in order to add a tag (that you may want to experiment
with). The collection process should just gather *all* tags, and
leave it to runtime to interpret them.

Note: This does not mean that the tags can't be validated for internal
consistency during buildtime.

 + Maybe reduce coupling inside the model. It makes for difficulty in
   extending it. For example, you can't get the SecurityDescriptors
   from the Type class. In Commons-Attributes you'd do:

     Attributes.getAttributes (myComponentClass,
PermissionDescriptor.class);

   Instead of accessing everything via the Type class. This means that
   if you add a descriptor class, you don't have to extend the
   Type class in order to access it.

 + I really don't like the generic Descriptor class either.
   Not typesafe enough with its getAttributeNames method.

/LS



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


Mime
View raw message