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 | *-----------------------------------------------------*
