{"id":456,"date":"2011-12-19T00:23:46","date_gmt":"2011-12-18T23:23:46","guid":{"rendered":"http:\/\/doanduyhai.wordpress.com\/?p=456"},"modified":"2011-12-19T00:23:46","modified_gmt":"2011-12-18T23:23:46","slug":"advanced-aspectj-part-iii-non-kinded-pointcuts","status":"publish","type":"post","link":"https:\/\/www.doanduyhai.com\/blog\/?p=456","title":{"rendered":"Advanced AspectJ part III : non-kinded pointcuts"},"content":{"rendered":"

Today we will focus on non-kinded poincuts of AspectJ.<\/p>\n

Unlike kinded pointcuts (method execution, field access, object initialization …), non-kinded pointcuts select join point on some criteria other than the join point signature (no kind). For example it is possible to select join points inside the source code(lexical structure) of a Java class or method. <\/p>\n

<\/p>\n

I Case study<\/h1>\n

Below is a simple case study.<\/p>\n

Let’s say you need to code an exception logger for your application. This is a cross-cuting concern so you naturally think about AspectJ and around()<\/em> pointcut, good thing !<\/p>\n

\n\t...\n\tpointcut exceptionPointCut(): execution(* com.myapp..*(..)) \n\t...\n\n\tObject around() : exceptionPointCut()\n\t{\n\t\tObject retValue = null;\n\t\t\n\t\ttry\n\t\t{\n\t\t\tretValue = proceed();\n\t\t}\n\t\tcatch(RuntimeException rte)\n\t\t{\n\t\t\t\/\/ Do something to process exception\n\t\t}\n\t\t\n\t\treturn retValue;\n\t}\n<\/pre>\n
What is wrong in the above aspect is not the around()<\/em> advice itself, which is perfectly valid and sensitive. No, what is wrong is the design of pointcut. <\/p>\n
The problem with the exceptionPointCut() is that it is capturing far too many join points, more than necessary. But how can it be possible ? The pointcut restricts itself to execution of any method in the com.myapp<\/strong> package and all its sub-packages !<\/p>\n
Yes, but this restriction is not enough. It means that all methods execution<\/strong> in your application will be avised by this pointcut, which is quite alot.<\/p>\n
Ask yourself, do I really need to track exceptions when calling getters\/setters for entities or DTO objects<\/em> ?  Do I really need to track exceptions in stateless helper classes with a high unit test coverage<\/em> ?<\/p>\n
The idea is to restrict further the method execution join points. For this you have some options:<\/p>\n
    \n
  1. \nbe more specific in the execution join point definition, by listing all classes you’ll like to monitor, it can be tedious: execution(* com.myapp.xxx.Class1(..)) || execution(* com.myapp.xxx.Class1(..))<\/em> …<\/li>\n
     <\/p>\n
  2. \nbe more specific by giving a method name pattern. This is the most efficient strategy but it is not always applicable and is very use case-dependent : execution(* com.myapp..do*(..))<\/em><\/li>\n
     <\/p>\n
  3. \nrely on non-kinded pointcuts<\/strong>, discussed below<\/li>\n<\/ol>\n
     <\/p>\n
    II Non-kinded poincuts<\/h1>\n
    There are 3 families of non-kinded pointcuts:<\/p>\n