You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Peter Donald <do...@apache.org> on 2001/06/01 19:57:16 UTC
[DISC] Aspect types was [DISC] Aspect implementation
Hi,
An important thing in AOP/SOC is finding the right "hinge points". A hinge
point is a point in code which needs to be flexible so that arbitrary
cross-cutting concerns can be plugged in.
For example one hinge point in Ant would be what to do with exceptions
generated either pre-execute() or during execute(). This hinge point is
required by aspects who want to implement fail-on-error style functionality.
Another hinge points would be - before/after tasks
instantiation/destruction (So you could time task, set context classLoader,
other)
So before we define the Aspect interface I think we should try to generate
a list of aspects that we think would be valid to implement. After that we
can list the hinge points. Some hinge points will be used in unison (ie
pre-create/post-destroy pair) and high correlation of use.
We then have to decide whether we list all the hinge points in one
interface or delegate them to multiple typed interfaces. This would be
based on correlation of use and size of interface. The first apprach
doesn't scale well but is fine if there is a small number of hinge points.
I guess you can look at TC3 vs TC4 to see how different designs play out.
TC3 is far easier to build initially but difficult to extend without
pissing off a bunch of interceptor writers ;) TC4 is harder for container
writers to initially build but simple to extend. It also scales better well
(though this is not likely to be an issue with ant???). Some would argue
that TC3 is easier because multiple hinge points are usually used together.
BTW you seem to be using the term join points synonymously with what I have
termed hinge points. Is this true?
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [DISC] Aspect types was [DISC] Aspect implementation
Posted by Peter Donald <do...@apache.org>.
No one has commented on this yet ... theres more issues that need to be
addressed in regards to this but I don't want to deluge the group yet so ...
At 03:06 PM 6/5/01 +1000, Peter Donald wrote:
>Hi,
>
>just had a whack at an interface that tried to fit all the different types
>of Aspects in. I have attached it and are interested in any feedback.
>
>A few things to consider. It currently uses Configuration objects for
>TaskModel but this will be changed to whatever format Ant2 uses. Also it
>has a separate method at start that takes task-model and returns a
>task-model. This is to allow aspects who want to modify TaskModel including
>adding new aspect parameters to model.
>
>Is there any feature this doesn't support that you would find useful ? or
>any other thoughts?
>
>Attachment Converted: "g:\applications\eudora\attach\AspectHandler.java"
>
>Cheers,
>
>Pete
>
>*-----------------------------------------------------*
>| "Faced with the choice between changing one's mind, |
>| and proving that there is no need to do so - almost |
>| everyone gets busy on the proof." |
>| - John Kenneth Galbraith |
>*-----------------------------------------------------*
>
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [DISC] Aspect types was [DISC] Aspect implementation
Posted by Peter Donald <do...@apache.org>.
Hi,
just had a whack at an interface that tried to fit all the different types
of Aspects in. I have attached it and are interested in any feedback.
A few things to consider. It currently uses Configuration objects for
TaskModel but this will be changed to whatever format Ant2 uses. Also it
has a separate method at start that takes task-model and returns a
task-model. This is to allow aspects who want to modify TaskModel including
adding new aspect parameters to model.
Is there any feature this doesn't support that you would find useful ? or
any other thoughts?
Re: [DISC] Aspect types was [DISC] Aspect implementation
Posted by Peter Donald <do...@apache.org>.
At 10:09 AM 6/2/01 +1000, Conor MacNeill wrote:
>> BTW you seem to be using the term join points synonymously with what I
>have
>> termed hinge points. Is this true?
>>
>
>I took my terminology from the AspectJ stuff - where does yours come from?
Okay just looked at AspectJ - join points indicate an intersection between
aspect and your code but don't necessarily indicate flexability at that
point. Thus hinge points (which also indicate flexability) are subset of
joint points. Hinge points is a term that is in a lot of research. It has
been used in description of AOP/SOC but it predates that (was popular in
early OO crazy).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [DISC] Aspect types was [DISC] Aspect implementation
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
> BTW you seem to be using the term join points synonymously with what I
have
> termed hinge points. Is this true?
>
I took my terminology from the AspectJ stuff - where does yours come from?
Conor
Re: [DISC] Aspect types was [DISC] Aspect implementation
Posted by coconut forcoconuts <co...@yahoo.com>.
--- Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
> >
> > So before we define the Aspect interface I think
> we should try to
> generate
> > a list of aspects that we think would be valid to
> implement.
>
> That sounds a reasonable approach although I feel we
> may be able to
> identify the "hinge points" just from our
> understanding of how Tasks will
> be executed. The other thing I mentioned in a
> separte post is identifying
> to which elements or tasks the aspect is to be
> associated. With a debugging
> aspect, for example, we may want to apply to a
> number of task types without
> having to enter aspect style attributes into each
> task declaration. This
> might lead us into what AspectJ calls pointcut
> designators. If so, we'll
> need some syntax for that. Or is that too complex
> for now.
>
> I don't think there will be many aspects in practice
> but you neve know.
> Anyway, the types of aspects to date I have
> considered
> failonerror control
> id definition
> debugging/tracing aspects
> perhaps logging but I haven't thought about it.
>
> Your example contained a doc: aspect but I had
> always theought that was
> piggy backed to the aspect concept as a way of
> ignoring some elements. That
> is, I didn't really expect the core to process these
> in anyway. Thoughts?
> Do we agree that an aspect can be in the build file
> without there being an
> aspect handler defined for that and if so, those
> aspect attributes are just
> ignored
>
> Any thought about aspects applied to either target
> or project elements?
>
> Let's see what other aspects people might find
> useful
>
> Conor
>
>
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
Re: [DISC] Aspect types was [DISC] Aspect implementation
Posted by coconut forcoconuts <co...@yahoo.com>.
--- Conor MacNeill <co...@cortexebusiness.com.au>
wrote:
> >
> > So before we define the Aspect interface I think
> we should try to
> generate
> > a list of aspects that we think would be valid to
> implement.
>
> That sounds a reasonable approach although I feel we
> may be able to
> identify the "hinge points" just from our
> understanding of how Tasks will
> be executed. The other thing I mentioned in a
> separte post is identifying
> to which elements or tasks the aspect is to be
> associated. With a debugging
> aspect, for example, we may want to apply to a
> number of task types without
> having to enter aspect style attributes into each
> task declaration. This
> might lead us into what AspectJ calls pointcut
> designators. If so, we'll
> need some syntax for that. Or is that too complex
> for now.
>
> I don't think there will be many aspects in practice
> but you neve know.
> Anyway, the types of aspects to date I have
> considered
> failonerror control
> id definition
> debugging/tracing aspects
> perhaps logging but I haven't thought about it.
>
> Your example contained a doc: aspect but I had
> always theought that was
> piggy backed to the aspect concept as a way of
> ignoring some elements. That
> is, I didn't really expect the core to process these
> in anyway. Thoughts?
> Do we agree that an aspect can be in the build file
> without there being an
> aspect handler defined for that and if so, those
> aspect attributes are just
> ignored
>
> Any thought about aspects applied to either target
> or project elements?
>
> Let's see what other aspects people might find
> useful
>
> Conor
>
>
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
RE: [DISC] Aspect types was [DISC] Aspect implementation
Posted by Peter Donald <do...@apache.org>.
At 12:45 PM 6/3/01 +0100, Jose Alberto Fernandez wrote:
>Should this be considered an Aspect on the Tasks or on
>Project/ProjectHelper?
I would say tasks at this stage .. though I am not sure we are going to be
differentiating yet.
>One feature of Preferences is that one does not need to define them on every
>use. They get applied depending on the concreate user environment (who the
>user is, for example).
right.
>So that looks more like an aspect to be applied at the level of the
>ProjectHelper. They will be specified independently of whatever project I am
>loading (in principle), so how can they be assuciated to the project. They
>may also define the proference for other aspects (like "run this task on
>debug mode"), without the need to modify the buildfile themselves (which may
>be a shared resource). We still can use whatever syntax for declaring and
>parameterizing aspects that we want.
Never thought of that - allowing preferences to "inject" other aspect
attributes. Could be useful .. I guess we need to test it out first.
> <aspect name="preferences" .... />
>
> <preference>
> <task name="javac">
> <attribute name="deprecation" value="false"/>
> <!-- Magic properties -->
> <attribute name="compiler" value="${build.compiler}"/>
> </task>
>
> <task name="*" >
> <!-- Seting aspect debug mode on ALL tasks -->
> <attribute name="ant:debug" value="true" />
> </task>
> </preferences>
fine by me - or we could use CSS like was suggested before (but that would
involve an extra parser depedency).
>Or something like that. My point here is that it is up to the preference
>aspect to define whatever syntax to express how preferences are defined.
agreed.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
RE: [DISC] Aspect types was [DISC] Aspect implementation
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Peter Donald [mailto:donaldp@apache.org]
>
> Hi,
>
> At 07:41 PM 6/2/01 +1000, Conor MacNeill wrote:
>
> For ages I have been trying to figure out a clean way to do
> preferences. In
> many ways preferences is a specialized form of templating .. namely if
> attribute foo not set and we have preference set for it then
> we set it.
> This could be done as a preference easily enough (something
> that gets hold
> of task model + task instance before execute() is called on task).
>
> +1 on Preferences == Aspect
>
Should this be considered an Aspect on the Tasks or on
Project/ProjectHelper?
One feature of Preferences is that one does not need to define them on every
use. They get applied depending on the concreate user environment (who the
user is, for example).
So that looks more like an aspect to be applied at the level of the
ProjectHelper. They will be specified independently of whatever project I am
loading (in principle), so how can they be assuciated to the project. They
may also define the proference for other aspects (like "run this task on
debug mode"), without the need to modify the buildfile themselves (which may
be a shared resource). We still can use whatever syntax for declaring and
parameterizing aspects that we want.
<aspect name="preferences" .... />
<preference>
<task name="javac">
<attribute name="deprecation" value="false"/>
<!-- Magic properties -->
<attribute name="compiler" value="${build.compiler}"/>
</task>
<task name="*" >
<!-- Seting aspect debug mode on ALL tasks -->
<attribute name="ant:debug" value="true" />
</task>
</preferences>
Or something like that. My point here is that it is up to the preference
aspect to define whatever syntax to express how preferences are defined.
> I am not sure - I think there should probably always be an
> aspect handler
> for it. However we could define a NoopHandler that would be
> installed for
> certain predefined aspects by default (much like DefaultListener is
> installed as ProjectListener by default).
>
> >Any thought about aspects applied to either target or
> project elements?
>
> It could be useful to have the adapter between
> tasks/target/project and
> ProjectListener as an aspect. But that is more a programatic advantage
> rather than advantage to build file users ;)
>
See my example above.
Jose Alberto
Re: [DISC] Aspect types was [DISC] Aspect implementation
Posted by Peter Donald <do...@apache.org>.
Hi,
At 07:41 PM 6/2/01 +1000, Conor MacNeill wrote:
>>
>> So before we define the Aspect interface I think we should try to
>generate
>> a list of aspects that we think would be valid to implement.
>
>That sounds a reasonable approach although I feel we may be able to
>identify the "hinge points" just from our understanding of how Tasks will
>be executed.
true - perhaps there could be others related to interaction between
targets/projects and/or changes of ExecutionFrame.
> The other thing I mentioned in a separte post is identifying
>to which elements or tasks the aspect is to be associated. With a debugging
>aspect, for example, we may want to apply to a number of task types without
>having to enter aspect style attributes into each task declaration.
nicer programatically and could be useful for tracing likethings .... hmmm
... wait...
Brilliant. On second thoughts this could be far far more useful. So every
aspect handler gets an opportunity to do something at each hinge/join
point? (or maybe every point they "register" for. I like.
For ages I have been trying to figure out a clean way to do preferences. In
many ways preferences is a specialized form of templating .. namely if
attribute foo not set and we have preference set for it then we set it.
This could be done as a preference easily enough (something that gets hold
of task model + task instance before execute() is called on task).
+1 on Preferences == Aspect
> This
>might lead us into what AspectJ calls pointcut designators. If so, we'll
>need some syntax for that. Or is that too complex for now.
man they have complex names for simple concepts ;)
>I don't think there will be many aspects in practice but you neve know.
>Anyway, the types of aspects to date I have considered
>failonerror control
>id definition
>debugging/tracing aspects
>perhaps logging but I haven't thought about it.
+1 for logging.
>Your example contained a doc: aspect but I had always theought that was
>piggy backed to the aspect concept as a way of ignoring some elements. That
>is, I didn't really expect the core to process these in anyway. Thoughts?
agreed.
>Do we agree that an aspect can be in the build file without there being an
>aspect handler defined for that and if so, those aspect attributes are just
>ignored
I am not sure - I think there should probably always be an aspect handler
for it. However we could define a NoopHandler that would be installed for
certain predefined aspects by default (much like DefaultListener is
installed as ProjectListener by default).
>Any thought about aspects applied to either target or project elements?
It could be useful to have the adapter between tasks/target/project and
ProjectListener as an aspect. But that is more a programatic advantage
rather than advantage to build file users ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [DISC] Aspect types was [DISC] Aspect implementation
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
>
> So before we define the Aspect interface I think we should try to
generate
> a list of aspects that we think would be valid to implement.
That sounds a reasonable approach although I feel we may be able to
identify the "hinge points" just from our understanding of how Tasks will
be executed. The other thing I mentioned in a separte post is identifying
to which elements or tasks the aspect is to be associated. With a debugging
aspect, for example, we may want to apply to a number of task types without
having to enter aspect style attributes into each task declaration. This
might lead us into what AspectJ calls pointcut designators. If so, we'll
need some syntax for that. Or is that too complex for now.
I don't think there will be many aspects in practice but you neve know.
Anyway, the types of aspects to date I have considered
failonerror control
id definition
debugging/tracing aspects
perhaps logging but I haven't thought about it.
Your example contained a doc: aspect but I had always theought that was
piggy backed to the aspect concept as a way of ignoring some elements. That
is, I didn't really expect the core to process these in anyway. Thoughts?
Do we agree that an aspect can be in the build file without there being an
aspect handler defined for that and if so, those aspect attributes are just
ignored
Any thought about aspects applied to either target or project elements?
Let's see what other aspects people might find useful
Conor