> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Berin Loritsch
>
> Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
>
> > -----Mensagem original-----
> > De: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> >
> >
> >>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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
