> From: Jonathan Hawkes [mailto:[EMAIL PROTECTED]
>
> Yes, very cool, but you didn't actually answer my question :)
>
> The thread had something do with AOP Aspects and their
> dependencies (I think). I believe one of the questions was,
> "should one aspect inherit its dependencies from another
> aspect". Actually, I never quite understood the thread; and
> that is why I asked for clarification. Sorry for the
> misunderstanding.
My bad. I just did a brain dump out to the list - I should
have provided background (as Niclas said).
Basically this is about reducing complexity in the container,
or rather, allowing the user of a container to decide just
how much complexity they want.
This is done by providing a very minimal kernel, to which one
can add kernel features called "Aspects" (I haven't come up with
a better name - any ideas?). The purpose of this is so that
the user of the container can understand the container in
terms of independent aspects that can be learned and analyzed
one at a time, and not a big ball of features.
For example, Merlin has something called Dependency Validation.
This means that the container will validate your components
and make sure that all dependencies are satisfied before even
starting the components. (ECM and Fortress will just happily start
components and run until one blows up.) The thing now is that
the contracts and metadata surrounding this functionality isn't
isolated in the container or the API - it is all over the place,
and coupled to other features of Merlin.
This means that in order to understand dependency validation,
you have to understand some other concepts, and in order to
understand them, yet some other concepts.
It's like a spaghetti meal - you can try to pick up just one
spaghetti, but the whole bunch will inevitably follow.
My attempt here is to separate parts of the container into
these "aspects" - for example, if you wanted dependency validation,
you would do:
myContainer.addAspect (new DependencyValidationAspect ());
and if you didn't want it, you'd just skip that step. Of course,
if you wanted to add dependency validation, you would have to
do a bit more than the above - you have to make sure your components
declare dependencies and so on - but the point here is that you
can sit down and learn dependency validation in isolation from other
aspects. You know, start off without it, and then one day when
you realize that "hmmm, dependency validation would be nifty",
you can read up on the three-four classes in
org.apache.avalon.aspects.validation, and just turn it on.
OK, so what is this thread about?
Well, it is about "what is an aspect"? I have given an example
of an aspect above - dependency validation. Logging is another
aspect.
Now, the problem is this - the dependency validator would like
to log some things - for example, which component it is validating,
and so on.
We must therefore apply the logging aspect to the dependency
validation aspect. I.e. give it a logger.
This is an example, not of inheritance between aspects, but when
one aspect (defined as "feature of the container") *requires* the
presence of another aspect (another feature of the container) in
order to function.
But since aspects are supposed to be independent (that's the point
of AOP - to make things that used to be intertwined in the program
code stand alone and independent, thus reducing coupling), that's
not really trivial. Besides, we'd like to *avoid having dependency
checking for aspects* - that just gives us a very complex kernel,
which was *precisely what we didn't want*, remember?
One can deal with this in several ways - some of which I've come
up with are:
+ Simply disallow a non-optional dependency on one aspect by another.
Aspects are supposed to be independent - that's the whole point
of them. If you start having non-optional dependencies, you have
picked the wrong aspect.
+ PicoContainer-style.
+ Optional Pico-style (hammetts demo)
+ ...
I hope this explains what it is I'm trying to do - please
ask more if I'm unclear, I'm not quite sure what I'm on about
myself.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
