You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2004/03/05 16:41:23 UTC

Aspects/Appliances (was: RE: Under Merlin's hood)


> From: Farr, Aaron [mailto:Aaron.Farr@am.sony.com] 
>
> > We have to look over all features in Merlin, and then see how these 
> > could be implemented as "aspects" (or whatever we'll end up calling 
> > them), and figure out what the Aspect interface will look 
> like and so 
> > on...
> 
> Attached is my idea of how this architecture would look.  
> (Sorry my ASCII art just couldn't cut it).
> 
> Point of the picture is that I hope the big box ("Avalon Container /
> Kernel") could be flexible enough to meet your design ideas.  
> In fact, there could easily be multiple implementations of 
> this beast.  One might look very similar to what Merlin is 
> now (started up by the Repository) while another might look 
> like your "myContainer" example.  The parts inside would be
> (somehow) completely pluggable and several should be optional.
> 
> Thoughts?

Looks like what I want, except the "Facilities" are also "aspects".

For example, the respository:

  An aspect that either:

    + listens to events applianceAdded/applianceRemoved

    + when triggered by some external input

  Tries to validate the dependencies in the container (see my email
  to Alex about that), and for the unresolved deps, starts adding
  appliances (component handlers) by going to the local or remote 
  respository.

The HTTP interface:

  Scans for HTTPAware component handlers and exposes them.

Managing POJOs:

  POJOComponentHandler / POJOAppliance

And so on...

It seems like we're on the same track.

/LS


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


RE: Aspects/Appliances (was: RE: Under Merlin's hood)

Posted by Alex Karasulu <ao...@bellsouth.net>.
Leo,

> > Point of the picture is that I hope the big box ("Avalon Container /
> > Kernel") could be flexible enough to meet your design ideas.
> > In fact, there could easily be multiple implementations of
> > this beast.  One might look very similar to what Merlin is
> > now (started up by the Repository) while another might look
> > like your "myContainer" example.  The parts inside would be
> > (somehow) completely pluggable and several should be optional.
> >
> > Thoughts?
> 
> Looks like what I want, except the "Facilities" are also "aspects".
> 
> For example, the respository:
> 
>   An aspect that either:
> 
>     + listens to events applianceAdded/applianceRemoved
> 
>     + when triggered by some external input
> 
>   Tries to validate the dependencies in the container (see my email
>   to Alex about that), and for the unresolved deps, starts adding
>   appliances (component handlers) by going to the local or remote
>   respository.
> 
> The HTTP interface:
> 
>   Scans for HTTPAware component handlers and exposes them.
> 
> Managing POJOs:
> 
>   POJOComponentHandler / POJOAppliance
> 
> And so on...
> 
> It seems like we're on the same track.
> 
> /LS

Excuse the one liner but this is marvelous news.

Alex




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