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
All,

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

                        -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?

One solution is to apply aspects to each other, and force all
dependencies 
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
if/when 
a logging aspect is added). Another "solution" would be to have the
aspects 
declare dependencies, maybe via some sort of metadata... well, you can
see 
where that line of thought leads!

The interactions of different aspects is also a place where one can
easily 
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
by 
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
would 
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
jar:install". 
Why? Well, it turns out that install-snapshot *changes the name of the
Jar 
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
is 
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
(logging, 
security) in isolation that you previously had to consider together with
a 
lot of other things, having coupling between aspects is just...
not-aspect 
oriented, I guess.

                        -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 would instantly cut the number of concepts in half, and that's
good.)

I had this one pointed out to me, and my reflexive answer was "no". I
still 
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
not 
dealt with by an Aspect? For example, why should three Avalon 4
components 
be hosted inside three Avalon4Handlers and not managed by a single 
Avalon4Aspect?

This is my motivation: The purpose of a container is to manage
components 
and provide unified access to them via some kind of lookup mechanism.
The 
purpose of an Aspect is to provide some specific non-unified
functionality. 
For example, suppose we have Aspects and Handlers. We have two
components, 
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
care 
whether it is an Avalon4Handler or a PicoHandler. If the A4 component
had 
been hosted inside an A4Aspect, and the PicoComponent inside a
PicoAspect 
we would have to first look up the right aspect, and then query the
aspect 
for the component.

Therefore it is superior to split functionality into Aspects and
Handlers.

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

                        -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? The
Fortress 
answer to that is "the container". You give Fortress URLs or files, and
it 
will parse them and set itself up accordingly.

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

The configuration parsing and all that stuff should be done by the code 
hosting the container. The container itself should only have an api
where 
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
be 
separate.

/LS


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


Mime
View raw message