You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Conor MacNeill <co...@cortexebusiness.com.au> on 2001/06/01 15:30:57 UTC
[DISC] Aspect implementation
I'd like to initiate a discussion of aspect implementation. I think we have
some level of agreement that we will have aspects but no real clear idea
about how they will look. I have done an initial implementation of an
aspect in mutant. It handles the "id" attribute in something like this
<fileset ant:id="std.fileset"
dir="jakarta-ant/proposal/mutant">
</fileset>
The "ant:" triggers the aspect The aspect is defined in the antlib.xml with
this statement
<aspect prefix="ant"
classname="org.apache.ant.component.core.AntAspectHandler"/>
Note that the id attribute in Ant1 is an implicit aspect, as it is handled
by the ProjectHelper.
The AspectHandler interface currently looks like this
public interface AspectHandler {
void setAspectContext(ExecutionContext context);
void beforeConfigElement(Object element) throws ExecutionException ;
void afterConfigElement(Object element) throws ExecutionException ;
}
The beforeXXX and afterXXX methods in the interface represent the join
points of the ant execution. There will be more added, especially dealing
with task execution, perhaps
void beforeExecuteTask
void aroundExecuteTask
void afterExecuteTask
Now, the question I really am concerned with here is the lifetime of the
aspect instance. I wanted to use introspection (via the mutant equivalent
of IntrospectionHelper), to configure the attributes of the aspect. So in
the above aspect, I provide a setId method to capture the value of the
"ant:id" attribute.
So, at the moment, I am doing the following
1. create the aspect handler instance
2. call beforeConfigElement
3. configure the element (configuring involves passing the values from the
project model (proxy) to the execution element)
4. call afterConfigElement
5. throw away aspect handler instance.
For task execution, I would create a separate instance of the same aspect
handler and perform a similar procedure. I'm wondering if this is the right
way. I see other alternatives
1. Associate an aspect handler instance with each element and invoking the
appropriate operation on this aspect when the element goes through the join
point.
2. Have a single instance of the aspect handler handling all elements which
invoke that aspect.
3. What I have currently with mutant, a separate instance for each joint
point group.
1. Seems OK, I guess - can be configured when the associated element is
configured.
2. may have difficulties with configuration and multithreading.
3. implies a stateless aspect (or one which stores and finds its state for
each join point group).
Another issue for aspects will be how to guarantee they are invoked for the
tasks which are controlled by a TaskContainer task. Hmm.
Thoughts?
Conor
Re: [DISC] Aspect implementation
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
For those who are unfamiliar with the concept of aspects, you can try the
following links which discuss AspectJ, an implementation of aspects for
Java.
http://aspectj.org/servlets/AJSite
http://aspectj.org/doc/gettingStarted/index.html
I'd also like to raise a further point. Currently I am only triggering an
aspect when there is some attribute value that use's the aspect's prefix in
its namespace. However, I can see some value for aspects invoked regardless
of the presence of such attributes. A debugging aspect might be an example.
So, we may need some way of defining pointcuts to apply aspects.
Conor
----- Original Message -----
From: "Conor MacNeill" <co...@cortexebusiness.com.au>
To: <an...@jakarta.apache.org>
Sent: Friday, June 01, 2001 11:30 PM
Subject: [DISC] Aspect implementation
> I'd like to initiate a discussion of aspect implementation. I think we
have
> some level of agreement that we will have aspects but no real clear idea
> about how they will look. I have done an initial implementation of an
> aspect in mutant. It handles the "id" attribute in something like this
>
> <fileset ant:id="std.fileset"
> dir="jakarta-ant/proposal/mutant">
> </fileset>
>
> The "ant:" triggers the aspect The aspect is defined in the antlib.xml
with
> this statement
> <aspect prefix="ant"
> classname="org.apache.ant.component.core.AntAspectHandler"/>
>
> Note that the id attribute in Ant1 is an implicit aspect, as it is
handled
> by the ProjectHelper.
>
> The AspectHandler interface currently looks like this
> public interface AspectHandler {
>
> void setAspectContext(ExecutionContext context);
>
> void beforeConfigElement(Object element) throws ExecutionException ;
> void afterConfigElement(Object element) throws ExecutionException ;
> }
>
> The beforeXXX and afterXXX methods in the interface represent the join
> points of the ant execution. There will be more added, especially dealing
> with task execution, perhaps
>
> void beforeExecuteTask
> void aroundExecuteTask
> void afterExecuteTask
>
> Now, the question I really am concerned with here is the lifetime of the
> aspect instance. I wanted to use introspection (via the mutant equivalent
> of IntrospectionHelper), to configure the attributes of the aspect. So in
> the above aspect, I provide a setId method to capture the value of the
> "ant:id" attribute.
>
> So, at the moment, I am doing the following
> 1. create the aspect handler instance
> 2. call beforeConfigElement
> 3. configure the element (configuring involves passing the values from
the
> project model (proxy) to the execution element)
> 4. call afterConfigElement
> 5. throw away aspect handler instance.
>
> For task execution, I would create a separate instance of the same aspect
> handler and perform a similar procedure. I'm wondering if this is the
right
> way. I see other alternatives
>
> 1. Associate an aspect handler instance with each element and invoking
the
> appropriate operation on this aspect when the element goes through the
join
> point.
> 2. Have a single instance of the aspect handler handling all elements
which
> invoke that aspect.
> 3. What I have currently with mutant, a separate instance for each joint
> point group.
>
> 1. Seems OK, I guess - can be configured when the associated element is
> configured.
> 2. may have difficulties with configuration and multithreading.
> 3. implies a stateless aspect (or one which stores and finds its state
for
> each join point group).
>
> Another issue for aspects will be how to guarantee they are invoked for
the
> tasks which are controlled by a TaskContainer task. Hmm.
>
> Thoughts?
>
> Conor
>
>
>
RE: [DISC] Aspect Representation was [DISC] Aspect
implementation
Posted by Peter Donald <do...@apache.org>.
At 11:16 AM 6/5/01 +0100, Jose Alberto Fernandez wrote:
>An orthogonal question, why is it ID an aspect but REFID is not? Shouldn't
>they represent the two sides of the same coin?
Who saids id should be an aspect ? ;)
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 Representation was [DISC] Aspect implementation
Posted by Stefan Bodewig <bo...@apache.org>.
Jose Alberto Fernandez <j_...@yahoo.com> wrote:
> In your other message you had a type id being declared inside a
> projectref. Which I think is the right thing to do.
To some extent <ant*>, <projectref> and container tasks are special -
but I agree that it doesn't look consistent.
> The problem I see today is this diferentiation between types using
> ID aspects and normal properties using name. At the usage level the
> visibility rules for both should be the same. Shouldn't <property
> name="X".../> be syntax sugar for <property ant:id="X".../>.
Yes. I think this is what we've agreed upon for Ant2.
> This would also mean the precedence rules that apply to <properties>
> must apply to ids also. Is that the case today?
Not today, but decided for Ant2 IIRC. We've not decided how scoping
and precedence of properties and other data-types will be, but that
they will be the same for all of them.
> An orthogonal question, why is it ID an aspect but REFID is not?
If ID is an aspect, then REFID should probably be one as well,
especially since REFID could be used to not create a new instance of
something at all (but pass in the referenced instance of a data-type).
Stefan
RE: [DISC] Aspect Representation was [DISC] Aspect implementation
Posted by Jose Alberto Fernandez <j_...@yahoo.com>.
> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> Conor MacNeill <co...@cortexebusiness.com.au> wrote:
>
> > Now when I dealt with that in mutant, I wondered whether we should
> > continue to support that or only allow data type values to be
> > defined at the top (task level), if you know what I mean.
>
> +1 on not supporting the id aspect on data types nested into tasks.
>
Before we make any decision, can we do everything we want to do with types
outside takss? In your other message you had a type id being declared inside
a projectref. Which I think is the right thing to do. HOw about passing type
values in <ant*> calls?
The problem I see today is this diferentiation between types using ID
aspects and normal properties using name. At the usage level the visibility
rules for both should be the same. Shouldn't <property name="X".../> be
syntax sugar for <property ant:id="X".../>.
We already decided to consolidate the namespaces. I think we should
consolidate also how they handle the namespace. This would also mean the
precedence rules that apply to <properties> must apply to ids also. Is that
the case today?
An orthogonal question, why is it ID an aspect but REFID is not? Shouldn't
they represent the two sides of the same coin?
Jose Alberto
Re: [DISC] Aspect Representation was [DISC] Aspect
implementation
Posted by Peter Donald <do...@apache.org>.
At 10:19 AM 6/5/01 +0200, Stefan Bodewig wrote:
>I've not come up with something that would be called an aspect that
>would manifest itself in an attribute for things other than tasks, but
>that doesn't necessarily imply that we can savely restrict
>attribute-aspects to tasks.
>
>How much do we gain if we use a restriction like this (you know, I'm
>not trying to prototype something myself)?
simplicity for user, simplicity for developer.
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 Representation was [DISC] Aspect implementation
Posted by Stefan Bodewig <bo...@apache.org>.
Conor MacNeill <co...@cortexebusiness.com.au> wrote:
> Now when I dealt with that in mutant, I wondered whether we should
> continue to support that or only allow data type values to be
> defined at the top (task level), if you know what I mean.
+1 on not supporting the id aspect on data types nested into tasks.
> Anyway, it is a usecase of aspects occuring at the element rather
> than task level.
It all depends a little bit on what kind of aspects we'll end up
with.
I've not come up with something that would be called an aspect that
would manifest itself in an attribute for things other than tasks, but
that doesn't necessarily imply that we can savely restrict
attribute-aspects to tasks.
How much do we gain if we use a restriction like this (you know, I'm
not trying to prototype something myself)?
Stefan
Re: [DISC] Aspect Representation was [DISC] Aspect
implementation
Posted by Peter Donald <do...@apache.org>.
At 07:28 PM 6/2/01 +1000, Conor MacNeill wrote:
>> * Only the top level task element has aspect "attributes" (though this
>> would change with container tasks - more on this later)
>
>Actually if you consider the id attribute in Ant1 to be a primitive form of
>Aspect, it can occur in any XML element. So, I can define a fileset nested
>deepy in some task's model and have that fileset referenced elsewhere.
>Something like this
>
><blah>
> <fileset ant:id="blah.fileset"/>
></blah>
>
><blah2>
> <fileset refid="blah.fileset"/>
></blah2>
In this particular use case I don't think we should support it. If the user
wants named filesets rather than anonymous ones they should define them
outside task. Then all tasks that use fileset refid it ;)
>Now when I dealt with that in mutant, I wondered whether we should continue
>to support that or only allow data type values to be defined at the top
>(task level), if you know what I mean.
+1
>Anyway, it is a usecase of aspects
>occuring at the element rather than task level. Thoughts?
no idea - I can think of use cases when writing container tasks. But not
otherwise - though haven't really played with it much. It just starts to
get complicated for us to do I guess.
>> I believe that application of these rules will allow most aspects to be
>> built but still allowing ease of implementation for both us and the
>aspect
>> writers.
>>
>> It will also be simpler IMHO for build file writers ... though I am not
>> sure about this yet. Need to test it more.
>>
>> Thoughts on this?
>>
>
>We have basically agreed on the TaskContext concept to define how tasks
>interact with the core. I extended this in mutant to become an
>ExecutionContext with is passed to both tasks and aspects. What do you
>think?
personally I can't seen any reason to allow task writers in general to
access (or even know about) aspects or taskdefs etc. In a few cases it may
be relevent (ie aspect-def/task-def tasks) but they should be treated as
special cases rather than general run of the mill.
In my experiments I founf there was generally two types of tasks.
"Privlidged" tasks and un-privlidged tasks. The privlidged tasks get access
to interfaces that allow them to interact with the ant runtime. Example
privlidged tasks would include;
* type-def tasks like aspect-def, task-def, mapper-def etc. (Need access to
TypeManager/Registry).
* ContainerTask - needs access to Task model and Execution engine (and
possibly access to the converter service to "interpret" it's own attributes).
* Facility tasks (ie like recorder for Ant1) that "install" an aspect.
* ant-call/ant/etc need access to Project model, ProjectManager and
possibly the ProjectBuilder.
>If not, what sort of interface should we provide to aspects from the
>core?
Personally the only interface I think we should provide is one to
install/uninstall a aspect. The event direction between tasks/aspects is
mediated by the runtime who has complete control over that.
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 Representation was [DISC] Aspect implementation
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Saturday, June 02, 2001 3:23 AM
Subject: [DISC] Aspect Representation was [DISC] Aspect implementation
> At 11:30 PM 6/1/01 +1000, Conor MacNeill wrote:
> >I'd like to initiate a discussion of aspect implementation. I think we
have
> >some level of agreement that we will have aspects but no real clear idea
> >about how they will look.
>
> I am not so sure about that ;) I think first we should discuss how things
> will be represented in buildfile first,
Sure. Good idea. I wasn't trying to force an implementation. Just after
doing some prototyping I had found some issues and thought it was an
opportune time to talk through them and see what other people think an
aspect is going to be.
> what type of aspects we will
> support and then finally goto implementation ;) This was on my list of
> things to discuss before I stopped sending them out.
>
> First - representation. Currently I would prefer to support the following
> style of aspect integration
>
> <mytask ant:id="foo" ant:classpath="..." ex:fail-on-error="false">
> <doc:description>Blah blah blah.</doc:description>
> <some-sub-element ... />
> </mytask>
>
> The important points in the above example are;
> * aspect "elements" (ie doc:description) do not have any attributes or
> sub-elements from another namespace
Hmmm, I hadn't even really considered aspect elements. I guess they are
cool.
> * Only the top level task element has aspect "attributes" (though this
> would change with container tasks - more on this later)
Actually if you consider the id attribute in Ant1 to be a primitive form of
Aspect, it can occur in any XML element. So, I can define a fileset nested
deepy in some task's model and have that fileset referenced elsewhere.
Something like this
<blah>
<fileset ant:id="blah.fileset"/>
</blah>
<blah2>
<fileset refid="blah.fileset"/>
</blah2>
Now when I dealt with that in mutant, I wondered whether we should continue
to support that or only allow data type values to be defined at the top
(task level), if you know what I mean. Anyway, it is a usecase of aspects
occuring at the element rather than task level. Thoughts?
>
> I believe that application of these rules will allow most aspects to be
> built but still allowing ease of implementation for both us and the
aspect
> writers.
>
> It will also be simpler IMHO for build file writers ... though I am not
> sure about this yet. Need to test it more.
>
> Thoughts on this?
>
We have basically agreed on the TaskContext concept to define how tasks
interact with the core. I extended this in mutant to become an
ExecutionContext with is passed to both tasks and aspects. What do you
think? If not, what sort of interface should we provide to aspects from the
core?
Conor
[DISC] Aspect Representation was [DISC] Aspect implementation
Posted by Peter Donald <do...@apache.org>.
At 11:30 PM 6/1/01 +1000, Conor MacNeill wrote:
>I'd like to initiate a discussion of aspect implementation. I think we have
>some level of agreement that we will have aspects but no real clear idea
>about how they will look.
I am not so sure about that ;) I think first we should discuss how things
will be represented in buildfile first, what type of aspects we will
support and then finally goto implementation ;) This was on my list of
things to discuss before I stopped sending them out.
First - representation. Currently I would prefer to support the following
style of aspect integration
<mytask ant:id="foo" ant:classpath="..." ex:fail-on-error="false">
<doc:description>Blah blah blah.</doc:description>
<some-sub-element ... />
</mytask>
The important points in the above example are;
* aspect "elements" (ie doc:description) do not have any attributes or
sub-elements from another namespace
* Only the top level task element has aspect "attributes" (though this
would change with container tasks - more on this later)
I believe that application of these rules will allow most aspects to be
built but still allowing ease of implementation for both us and the aspect
writers.
It will also be simpler IMHO for build file writers ... though I am not
sure about this yet. Need to test it more.
Thoughts on this?
(I will send another mail about types of aspects needed).
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 implementation
Posted by Peter Donald <do...@apache.org>.
At 11:30 PM 6/1/01 +1000, Conor MacNeill wrote:
>1. Associate an aspect handler instance with each element and invoking the
>appropriate operation on this aspect when the element goes through the join
>point.
>2. Have a single instance of the aspect handler handling all elements which
>invoke that aspect.
>3. What I have currently with mutant, a separate instance for each joint
>point group.
>
>1. Seems OK, I guess - can be configured when the associated element is
>configured.
>2. may have difficulties with configuration and multithreading.
>3. implies a stateless aspect (or one which stores and finds its state for
>each join point group).
I think I prefer 2. If you recall a while back there was discussion of
"context" task (like recorder but generalized to all "aspects"). So you
could define a context that said log verbosly and do Y. This was given as
an alternative to aspects. After further discussion it was discovered that
"contexts" (which I call facilitys) are complimentry to aspects.
For example the example used was logging. In this case you configure the
facility to log to file foobar.txt with formatter Y and layout Z. The
logging facility was an AspectHandler. It could also take per-task
parameters (ie only log task at error level) which are provided by the
namespaced attributes/elements on task.
>Another issue for aspects will be how to guarantee they are invoked for the
>tasks which are controlled by a TaskContainer task. Hmm.
I can't see any problem here as I assume that we will just be handing back
the task proxy/model/configuration to executor and the executor will handle
all aspects.
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
[DISC] Aspect types was [DISC] Aspect implementation
Posted by Peter Donald <do...@apache.org>.
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 |
*-----------------------------------------------------*