avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] Container Components
Date Fri, 27 Jun 2003 18:38:39 GMT
Farr, Aaron wrote:

> 
>>-----Original Message-----
>>I would like to work with a basic extensible meta info library that is
>>lightweight, well-tested, and can be used in all containers.  We need
>>to work with the AMTAGS proposal, and fill in any holes.
> 
> 
> I think the best idea would be to work with the existing meta package under
> the sandbox and somehow combine that with the AMTAGS proposal.
> 
> Leo Simons sent out an email a while back and made a wiki entry on some
> concerns with the existing meta package and I never saw much discussion on
> it.  It was quite a critical review, but it might be a good place to start
> in terms of merging AMTAGS and the meta package:
> 
> http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonMerlinMetaTags

I'm sure Leo was writing down his thoughts so they were not forgotten.

We do need to get back on the stick with the Meta Info stuff.  I agree
with many of the points.  We should separate out that into another discussion.


>>IMO we should work with a Queryable interface as opposed to an object
>>model based one.  While an object model provides a certain ease of use,
>>it is not as extensible.  I am open to discussion on the matter, and
>>hopefully there will be reams of emails when I get back....
> 
> 
> I'm not sure I'm following your ideas on a queryable interface.  Perhaps a
> simple example would help?

I am playing around with .NET and C# Avalon Framework.  The Meta data in
C# is defined by something like this:

type.IsDefined(typeof(MyProj.MyAttributeType), inheritable == true);

Essentially I am talking about something like how our configuration is
set up.  If anything, we can model Types, Methods (i.e. lifecycle), and
Assemblies.

It would be easier to extend the system dynamically by allowing the
interface to querry if a type or method has a specific attribute or
not.  That way things like JMX integration can be treated as an add-in,
and the JMX publishing tool will be able to see which methods and types
have the attributes set.

It would make it easier to define standards for attributes so that we
can have multiple implementations of Management eXtensions if that were
necessary.

If we were required to define new MXType objects or MXMethod objects
to make things "easier" then we would have a problem with making our
container components truly portable.

We could have a simple Attribute interface like this:

public interface Attribute
{
     String getName();
     String getValue();
     String getParameter(String name);
}

That would provide the balance between extensibility and usability.


>>As to the Assembly information what do we need beyond the simple component
>>mapping?  What do we want to formally represent?
> 
> 
> Merlin's Appliance interface provides a good starting point I think.

Ok.

>>Also, how do we deal with components that have a lookup something like
>>URL protocol resolution (i.e. "http" pulls up the HTTP protocol handling
>>component and "ftp" pulls up the FTP protocol handling component)?
> 
> 
> Shouldn't we be able to build off of the source resolver for this?  Perhaps
> we need an Avalon naming (or lookup?) package which handles URI's and URL's
> better. This could then plug into source factories or other naming
> resolvers.

It was a metaphor.  If we want to get away from ServiceSelector (which I believe
we do), we need a way of mapping component implementations to each of those
short names.  For example, in Cocoon there are different types of generators
and transformers and serializers.  Each of them provides a different way
of doing things.  A "file" generator is different from a "image-directory"
generator, etc.

The sitemap that calls these components up does not know in advance that it
will need a "file" and a "image-directory" component.

It is a known requirement for an existing user.  We don't want to ignore
that use case.  We want to provide a better way of handling it, but we
don't want to ignore it.

It's not like we can go to the implementation and say that we will always
need the "file" and "image-directory" components because those requirements
are not known until the component reads the sitemap.xml configuration file.
I suppose that we should allow wildcards for declaring that meta info.

I am trying to get a feel for what would be best there.


>>How do we come to a middle ground with Phoenix, Merlin, and Fortress?
> 
> 
> Minimally the first steps would be to:
> 
> 1. Release meta package standard which includes standard AMTAGS
> 2. Release standard assembly package

:)  Yep.

> I think the container components mentioned thus far best fit within the
> scope of assembly adaptors or extensions.  Perhaps there would be the need
> for a third step:
> 
> 3. "Container Management API"
> 
> which would handle base extensions like instrumentation, management
> extensions and directory (lookup) extensions.  Maybe this is better called a
> Kernel API taking the idea of a Kernel from merlin.  This is the point where
> I'm not sure what would be best.  But minimally, the assembly and meta
> packages would be needed first.  Then we at least have something to work
> with and towards.

Let's start with the tools first, and see what evolves from there.  We do
have existing functionality for instrumentation and management extensions.
We can refactor those and where we have common requirements, we can create
the Container Management API from that.

-- 

"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


Mime
View raw message