You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2004/03/08 09:09:57 UTC
State of the Aspect
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
Re: State of the Aspect
Posted by Stephen McConnell <mc...@apache.org>.
Leo:
Three things (if I'm tracking this correctly) that you are raising:
1. interdependencies between aspects - My feeling is that
as aspect is independent, and if a dependency is identified, then
in fact your not looking at an aspect - instead its a system
of some kind. I also think you cannot deal with aspects in a
completely generic way - because I think aspects start to make
sense with a specific and concrete context (for example - the
"management aspects" of a component model). Establishing a
common context also means that you can eliminate things that
may initially be considered a dependency.
2. Concerning Aspects *and* Appliances (or Handlers) - am trying to
map this down to concrete things in Merlin and I think I need
some assistance.
I could imagine a component model be described through a
set of aspects - for example:
- logging management aspect
- configuration management aspect
- dependency management aspect
- context management aspect
- runtime aspect
With something like the above - the application of aspects
does not jump out at me as a benefit mainly because the set
of notions are well understood - however, lets dig a little
more into the configuration management and see if there is
something different here:
- default establishment
- modification
- validation
- change notification
Ok - here I'm starting to see the potential for a set of
things that could be added in a generic fashion, and I could
imagine re-applying logic under other areas such as dependency
management or context management.
Where does Appliance or Hander fit into this? I don't think
it does. Actually dealing with a component instance is part
of a runtime which is where we deal with different component
models, etc.
3. I agree.
Conclusion - Aspect oriented has the potential to make profiled
solutions more easy to archive. They also come at the expense of being
generic, and as such introduce complexity of their own. The trick (as
it looks to me) is to identify at what levels and in which context
aspects add value.
Cheers, Stephen.
Leo Sutic wrote:
> 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
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: State of the Aspect
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Alex Karasulu [mailto:aok123@bellsouth.net]
>
> > Instead, borrow from Pico;
> >
> > LoggerAspect loggerAspect = new LoggerAspectImpl( something );
> > kernel.addAspect( loggerAspect );
>
> You're dead on by looking at Pico for answers here.
That looks good - but I've been thinking about aspects and come up with
the following:
Since aspects are supposed to be different isolated aspects of the
system (that's why we started with AOP), having interdependent aspects
is a bit of not-quite-AOP, since the aspects aren't isolated anymore
and an indicator that the wrong aspects have been picked.
So I'm close to just disallowing any explicit dependencies.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: State of the Aspect
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> 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. *
>
> 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.
Yes we need to watch for this I think Leo's trying to avoid it with this
email.
> Instead, borrow from Pico;
>
> LoggerAspect loggerAspect = new LoggerAspectImpl( something );
> kernel.addAspect( loggerAspect );
You're dead on by looking at Pico for answers here.
> > -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.
I agree there may be some configuration beans that are setup and fed into
the constructor of these Aspects. In that sense there is none of this XML
based configuration going on. This kind of Configurable functionality
itself comes in as an aspect later.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: State of the Aspect
Posted by Niclas Hedhman <ni...@hedhman.org>.
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