avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: State of the Aspect
Date Mon, 08 Mar 2004 10:00:37 GMT
On Monday 08 March 2004 16:09, Leo Sutic wrote:
>                         -oOo-
>
> One problem is about interdependencies between aspects. Suppose you make
> logging an aspect. Then you make security an aspect. The implementation
> of
> the security aspect would likely like to log some messages. So how would
> this be done?

What is the Requirement?

* SecurityAspect needs to reach a LoggerAspect. *

Question at hand; Is LoggerAspect a service with a pluggable implementation, 
that can be changed by the deployer via a configuration file?

We are not re-implementing the container at a higher level (a.k.a 
uber-container). We don't need to make all the "magic" once again at this 
level.

Instead, borrow from Pico;

  LoggerAspect loggerAspect = new LoggerAspectImpl( something );
  kernel.addAspect( loggerAspect );

  SecurityAspect secAspect = new SecurityAspectImpl( loggerAspect );
  kernel.addAspect( secAspect );

Done deal! No need for "magic", IMHO.


>                         -oOo-
>
> The second big one is if there is any point in having Aspects *and*
> Appliances (or Handlers as I call them, since they are
> ComponentHandlers).
> Aren't Handlers just other aspects? Isn't there a Avalon4HandlingAspect?

This is perhaps tricky...
IMHO, a Handler are neither 'native' concept nor an Aspect. More like a value 
object of a particular aspect (activation category I guess).

But this notion could be a derived conclusion after being too merlinized.
A MerlinActivationAspect has Appliances, but would other component management 
systems really require Applicances?

The way I see it, you need 3 things for all this to work;
1. Kernel = The guy that manage the Aspects
2. DataManager = somewhere the Aspects can register and lookup data of any 
kind.
3. Aspects = some very central ones, that may always be required, and then all 
the optional ones. The trick is to boil down what is the 'foundation 
aspects', so one can step up from there.

This is perhaps a very different view from yours, and I think I need to 
understand the "Handler concept" a bit more, before having any strong opinion 
about it.


>                         -oOo-
>
> Third problem: I have a set of configuration files. Whose responsibility
> is it to load them and turn them into some kind of application? 

As I see it, the 'starting container' (which instantiates the Aspects) will 
for each Aspect need to provide enough information, for that Aspect to become 
operational, in its constructor.

I don't think there is any concept of configuration in this 'ultra-thin' 
mechanism.


Cheers
Niclas

P.S. I think the general crows here is pretty "blank" about your request, as 
they don't have all the background that I have, so perhaps an elaboration of 
the intent and approach is now appropriate :o)

-- 
+---------//-------------------+
|   http://www.bali.ac         |
|  http://niclas.hedhman.org   |
+------//----------------------+

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


Mime
View raw message