Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re: Re: [aspectj-users] around advice and modifying arguments


Peter,

Great, that does seem like a good approach. You can identify the type of argument and runtime and determine whether it is a String that needs expanding. Thanks for posting the answer that may be useful to others.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/



"Peter Koch" <Peter.Koch@xxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx

14/12/2006 10:53

Please respond to
aspectj-users@xxxxxxxxxxx

To
<aspectj-users@xxxxxxxxxxx>
cc
Subject
Re: Re: Re: [aspectj-users] around advice and modifying arguments





Hi Matthew!

We found a much simpler solution.

 /**
  * All set or add methods with at least one String param on all subclasses of
  * ULCProxy.
  *
  * @param object
  */
 pointcut setOrAdd2(Object object1, Object object2):
   ( execution(public void ULCProxy+.set*(*, String)) || execution(public void ULCProxy+.set*(String, *))
       || execution(public void ULCProxy+.add*(*, String)) || execution(public void ULCProxy+.add*(String, *)))
    && args(object1, object2);

 /**
  * Takes the params, modifies them if they are String instances and if there is a macro and executes the
  * method with the changed params.
  *
  * @param object1
  * @param object2
  */
 void around(Object object1, Object object2): setOrAdd2(object1, object2)
 {
   proceed(macroExpand(object1), macroExpand(object2));
 }

 /**
  * @param object
  * @return The expanded object, if it's a string and contains macros
  */
 private Object macroExpand(Object object)
 {
   if (object != null)
   {
     IMacroExpandBridge me = MacroExpandBridgeManager
         .getMacroExpandBridgeManager().getMacroExpandBridge();
     return me.macroExpand(object);
   }

   return object;
 }

With the pointcut defined above, we find all methods which have two arguments
and at least one of the arguments is a String.

Then, for all three arguments methods we use:

 /**
  * All set or add methods with at least one String param on all subclasses of
  * ULCProxy.
  *
  * @param object
  */
 pointcut setOrAdd3(Object object1, Object object2, Object object3):
   (execution(public void ULCProxy+.set*(*, *, String)) || execution(public void ULCProxy+.set*(*, String, *))
       || execution(public void ULCProxy+.set*(String, *, *))
       || execution(public void ULCProxy+.add*(*, *, String)) || execution(public void ULCProxy+.add*(*, String, *))
       || execution(public void ULCProxy+.add*(String, *, *)))
    && args(object1, object2, object3);


We fetch with this all arguments, also primitives (int, boolean, ...) work.

Now for four arguments:

 /**
  * All set or add methods with at least one String param on all subclasses of
  * ULCProxy.
  *
  * @param object
  */
 pointcut setOrAdd4(Object object1, Object object2, Object object3,
     Object object4):
   ( execution(public void ULCProxy+.set*(*, *, *, String)) || execution(public void ULCProxy+.set*(*, *, String, *))
       || execution(public void ULCProxy+.set*(*, String, *, *)) || execution(public void ULCProxy+.set*(String, *, *, *))
       || execution(public void ULCProxy+.add*(*, *, *, String)) || execution(public void ULCProxy+.add*(*, *, String, *))
       || execution(public void ULCProxy+.add*(*, String, *, *)) || execution(public void ULCProxy+.add*(String, *, *, *))
       )
    && args(object1, object2, object3, object4);

You see, it's pretty easy and we have very few code at the end.



We found the solution thru sitting together/team-programming.

Thanks for your input and best regards,
Peter



Peter,

You will probably have to write one pointcut and piece of around advice
for every method where you want to process the String arguments. Using the
interface approach you will only have to define at most one interface per
advised class (with one interface method declaration per advised method).
These seems like less code and less effort plus each interface becomes a
easy-to-read specification, especially for non-AspectJ experts, for the
methods you are advising. I suggest you pick one class, perhaps the one
with the smallest number of methods to advise, and try both approaches to
see how they compare for simplicity, performance and maintainability.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx

http://w3.hursley.ibm.com/~websterm/_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users


Back to the top