avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject State of the Aspect
Date Mon, 08 Mar 2004 08:09:57 GMT

I'm working on the aspect-type container. I thought I'd be able to
a proposal today, but there are some issues that I want solved first
that I 
haven't been able to solve.


One problem is about interdependencies between aspects. Suppose you make

logging an aspect. Then you make security an aspect. The implementation
the security aspect would likely like to log some messages. So how would

this be done?

One solution is to apply aspects to each other, and force all
to be optional (i.e. the securityaspect will have to start off with a 
NullLogger, and then switch to whatever the logging aspect gives it
a logging aspect is added). Another "solution" would be to have the
declare dependencies, maybe via some sort of metadata... well, you can
where that line of thought leads!

The interactions of different aspects is also a place where one can
shoot onself in the foot bigtime. As an example, look at Maven. When I 
wrote Commons-Attributes I added a Maven plugin. It would kick in just 
before compiling Java sources and do the source code generation required
Commons-Attributes. The original sources and the generated sources would

then be picked up by the java:compile goal, and everything would be just

fine. I also added a post-processing step to the JAR packaging that
do "some stuff" to the created Jar file. Later I made two discoveries:

  1. When I prepared the excalibur releases I saw this line in the logs:
[attribute-compiler] Creating Attribute information...
Ooops. Looks like I just managed to add a dependency on 
commons-attributes-api to Excalibur!

  2. The post-processing of the Jar file didn't work when I ran "maven 
jar:install-snapshot", but worked just fine when I ran "maven
Why? Well, it turns out that install-snapshot *changes the name of the
file*, and furthermore, that *there is no way to find out what it was 
changed to*!

The lesson to learn from this is that while aspect-oriented programming
powerful, it is vital to keep the aspects decoupled as much as possible,

and when coupling is required, to do so with a well-defined interface. 
Since the purpose of aspects is to allow one to consider things
security) in isolation that you previously had to consider together with
lot of other things, having coupling between aspects is just...
oriented, I guess.


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

(This would instantly cut the number of concepts in half, and that's

I had this one pointed out to me, and my reflexive answer was "no". I
think it the right answer is "no", but I can't motivate it, and that's a

sure sign that I am dead wrong. Here's an attempt at a motivation:

Why should management of components be split into several Handlers and
dealt with by an Aspect? For example, why should three Avalon 4
be hosted inside three Avalon4Handlers and not managed by a single 

This is my motivation: The purpose of a container is to manage
and provide unified access to them via some kind of lookup mechanism.
purpose of an Aspect is to provide some specific non-unified
For example, suppose we have Aspects and Handlers. We have two
one of them is an Avalon4 component, the other is a PicoContainer 
component. In this case we have a set of aspects, one Avalon4Handler and

one PicoHandler. When we're looking for one of the components, we simply

look up the handler directly and get the component. We don't have to
whether it is an Avalon4Handler or a PicoHandler. If the A4 component
been hosted inside an A4Aspect, and the PicoComponent inside a
we would have to first look up the right aspect, and then query the
for the component.

Therefore it is superior to split functionality into Aspects and

Counterargument: Yes, but the ability to find components by lookup key
also an aspect of a container. Consider a ComponentDirectoryAspect. The 
A4HandlingAspect would register itself there as the provider for
with certain lookup keys, and the PicoHandlerAspect would do the same.


Third problem: I have a set of configuration files. Whose responsibility
it to load them and turn them into some kind of application? The
answer to that is "the container". You give Fortress URLs or files, and
will parse them and set itself up accordingly.

I happen to think that it is not the container's responsibility to do

The configuration parsing and all that stuff should be done by the code 
hosting the container. The container itself should only have an api
you could add Aspects and component handlers - thus decoupling it from a

configuration file format and making it easily embeddable.

Providing a default config file format is good, though, but this should


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

View raw message