avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject [RT] New beginning & meta
Date Fri, 01 Aug 2003 14:49:04 GMT
Berin Loritsch wrote:
>
> 1) Keep them in the Avalon namespace.  Implication: no change to the
library
>     at all.
> 
> 2) Put them in the Lifecycle namespace.  Implication: change to the
ANT task
>     to collect the information.
> 
> 3) Scrap the whole thing and use a more generic library.  Implication:
the
>     Avalon meta package goes in the crapper, and we use something like
Commons
>     Attributes (some work has to be done with that as they don't
support the
>     name="value" notation for tags).
 
I have thought some about the AMTAGS proposal, the metainfo and all
that.
Basically, my conclusion is that this information is being generated at
the
wrong point in the build, and that we are generating the wrong
information.

As it is now we have:

  source code --+-- javac       --> .class file    --+--> .jar
                |                                    |
                +-- infobuilder --> metainfo file  --+

The "infobuilder" application above is container specific, meaning that
if
I want to be able to run a component in Fortress and Merlin, I have to
either:

  source code --+-- javac       --> .class file    --+--> .jar
                |                                    |
                +-- fortressbld --> fortress file  --+
                |                                    |
                +-- merlinbldr  --> merlin file    --+

Or somehow make Fortress or Merlin read and understand each other's
metainfo files.

So in order to have cross-container deployment in two containers, those
containers must:

 1. Observe and recognize a common set of tags.

 2. Have the same metainfo file format.

 3. Interpret the metainfo in the same way: Each metainfo file describes
    something about a component, and the container will then typically
*do*
    *something* in response to that. For example, if I load a Poolable
Fortress 
    component in Merlin, the container cannot allow concurrent access to
it.

Why is this a problem? Well, look at the latest controversy on whether
to
call a tag @lifecycle.stage or @avalon.stage. This causes problems in
the
following steps:

 1. A infobuilder has to *explicitely disallow* some tags. That is, if I
    have a component marked as @avalon.stage, then the Infobuilder must
    throw an error here ***irrespective of whether the target container 
    supports the tag or not***.

 2. The metainfo builder is locked to the name of the tag, so you never
get
    it in the resulting file.

Now, I think we can simply get rid of steps 1 and 2. Leaving 3, but that
one is
the easiest, I think.

Consider .Net: When you add attributes to something, *all* attributes
get compiled
in. It is then deferred to runtime which attributes are to be
recognized.

I think this would solve a lot. First, we could use *one* metainfo
builder for
all containers. That builder would be forward-compatible and
container-agnostic.
You could experiment as much as you wanted with new container features.

Second, since all containers use the same metainfo builder, they all
read the same
file format. (Or use the same API to access it).

This means that two out of three points required for cross deployment
are solved.

It also means that we only have to agree on which attributes are
recognized Avalon-wide.

                               -oOo-

With the risk that this turns into a "Leo's Picks" column I am also
beginning to
like the way attributes are handled in .Net, with value objects. You'd
have:

    import org.apache.avalon.framework.attributes.ThreadSafe;
    import org.apache.avalon.framework.attributes.Dependency;

    /**
     *
     * @attribute new ThreadSafe()
     * @attribute new Dependency( MyDependency.class, "my-dep" )
     */
    public class MyComponent {
    }

This could be compiled into a .java file and then into a .class file:

    public interface AttributeClass {
        public Set getClassAttributes ();
    }

    import org.apache.avalon.framework.attributes.ThreadSafe;
    import org.apache.avalon.framework.attributes.Dependency;

    public class MyComponent$Attributes implements AttributeClass {
        public static final Set classAttributes = new HashSet ();
        static {
            classAttributes.add ( new ThreadSafe () );
            classAttributes.add ( Dependency( MyDependency.class,
"my-dep" ) );
        }

        public Set getClassAttributes () {
            return classAttributes;
        }
    }

A standard API would be able to access this via:

    Class c = MyComponent.class;
    Class attributeClass = c.getClassLoader ().loadClass ( c.getName +
"$Attributes" );
    AttributeClass instance = (AttributeClass)
attributeClass.newInstance ();
    Set classAttributes = instance.getClassAttributes ();

and so on...

Am thinking about whacking together a sample of this.

BTW - I remember seeing a sample of JSR175, Metadata for Java, but I
have
forgotten where.

/LS


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


Mime
View raw message