avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Attributes Proof of Concept
Date Mon, 11 Aug 2003 20:47:18 GMT
Leo Sutic wrote:

> A while ago I suggested that using attributes may be a way out of the
> problems we're having with meta models. The response then was that
> the idea sure seemed nice, but the implementation of the idea sure
> seemed nonexistent.

<snip type="cool stuff and code"/>

I noticed you used XDoclet instead of QDox.  Any particular reason why?

It doesn't really matter in the end.  Nice work.

I will like to play with it, and move toward something like this.

Now the next major question is this:

We currently have a need to discover the components that are available,
so that we can match up the services with the implementations.  It seems
that this will require some sort of extension to the classloader so that
we can find the classes that have attributes attached to them.

It is pretty messy to have to iterate over classes, but doable if necessary.
I would prefer a way to discover components that are already loaded on the
classpath.  That may not be possible.

I would be satisfied with a special classloader that had the extra method:

Class[] findClasses( Class attribute );

or something like that for class attributes.

For example, Fortress finds all the services, then finds the associated
components.  It does this by extending the JAR packaging mechanism with
the standard "services" JAR extension and a resource that contains a list
of services.

It would work with that approach, but the ultimate best option would to
not have to worry about the packaging criteria.

Currently we have three different ways of discovering components and
services.  While that is not horrendous, I would like to evolve toward
one way of discovering what is in the classloader.  If the tool can do
it for me, then there is little reason to use the Fortress approach to
extending the packaging requirements or Merlin doing the same.

Phoenix is a bit different because it assumes the assembler knows what
components are available, and the set of components are static.

Automatic discovery of components and such will enable things like IDE
plugins and ANT tools to assist the developer as they create and deploy
the system.


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

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

View raw message