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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
