Wednesday, September 23, 2015
Wednesday, May 6, 2015
Weaving AOP
Problem:
Quite often you end up with a 3rd Party server being down and here is how you can use AOP to stub the requests and ensure that your code is performing well.
You can use Load time weaving(LTW) to weave during run time.
Define your aop.xml
Define your Aspect
Ensure that the class your are cross cutting(com.sample.ThirdParty.call) is in classpath
When you are trying to integrate it with a custom server, please note that you need to have -javaagent
for eg
Call vs. Execution
The rule of thumb is that if you want to pick a join point that runs when an actual piece of code runs (as is often the case for tracing), use execution, but if you want to pick one that runs when a particular signature is called (as is often the case for production aspects), use call.
While its fairly easy to run the LTW, quite often I ended up having issues with loading it and this might help.
How do I get load-time weaving to work in my chosen application server?
You have two choices based on how wide you want the weaving to take effect: application-server wide and application-specific weaving. You choose between the two by loading aspect artifacts--aspects, associated types, and aop.xml--through the right classloader. The aop.xml must be in the META-INF directory on the classpath for the chosen classloader. In either case, you modify the startup script to specify the -javaagent:path-to/aspectjweaver.jar option to the Java virtual machine. Note that it is not essential that all the artifacts be placed in a single jar.
For application-server wide weaving, you make aspect artifacts accessible to the server's classloader. Typically, you achieve such access by putting these artifacts in the server's lib directory. For example, for Tomcat, you will place the aspect artifacts in the TOMCAT_HOME/lib directory.
For application-specific weaving, you make aspect artifacts accessible to application classloader by bundling them along with application's classes. For example, for a web application, you will place the aspect artifacts in the MY_APP/WEB-INF/lib and/or MY_APP/WEB-INF/classes directory.
We recommend that you start with application-specific weaving. Note that you have an additional option if your application is based on the Spring framework. If you deploy in one of the supported web servers or application servers, you can avoid modifications to the startup script. Please see http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-aj-ltw-spring for more details.
Reproduced content from http://eclipse.org/aspectj/doc/released/faq.php#q:ltwAppServers
When you don't know if your weaving agent is loaded or not, use the below code in your flow. If you get any of the exceptions, you know your agent is either not loaded or not instrumenting.
Quite often you end up with a 3rd Party server being down and here is how you can use AOP to stub the requests and ensure that your code is performing well.
You can use Load time weaving(LTW) to weave during run time.
Define your aop.xml
Define your Aspect
Ensure that the class your are cross cutting(com.sample.ThirdParty.call) is in classpath
When you are trying to integrate it with a custom server, please note that you need to have -javaagent
for eg
Call vs. Execution
The rule of thumb is that if you want to pick a join point that runs when an actual piece of code runs (as is often the case for tracing), use execution, but if you want to pick one that runs when a particular signature is called (as is often the case for production aspects), use call.
While its fairly easy to run the LTW, quite often I ended up having issues with loading it and this might help.
How do I get load-time weaving to work in my chosen application server?
You have two choices based on how wide you want the weaving to take effect: application-server wide and application-specific weaving. You choose between the two by loading aspect artifacts--aspects, associated types, and aop.xml--through the right classloader. The aop.xml must be in the META-INF directory on the classpath for the chosen classloader. In either case, you modify the startup script to specify the -javaagent:path-to/aspectjweaver.jar option to the Java virtual machine. Note that it is not essential that all the artifacts be placed in a single jar.
For application-server wide weaving, you make aspect artifacts accessible to the server's classloader. Typically, you achieve such access by putting these artifacts in the server's lib directory. For example, for Tomcat, you will place the aspect artifacts in the TOMCAT_HOME/lib directory.
For application-specific weaving, you make aspect artifacts accessible to application classloader by bundling them along with application's classes. For example, for a web application, you will place the aspect artifacts in the MY_APP/WEB-INF/lib and/or MY_APP/WEB-INF/classes directory.
We recommend that you start with application-specific weaving. Note that you have an additional option if your application is based on the Spring framework. If you deploy in one of the supported web servers or application servers, you can avoid modifications to the startup script. Please see http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-aj-ltw-spring for more details.
Reproduced content from http://eclipse.org/aspectj/doc/released/faq.php#q:ltwAppServers
When you don't know if your weaving agent is loaded or not, use the below code in your flow. If you get any of the exceptions, you know your agent is either not loaded or not instrumenting.
Subscribe to:
Posts
(
Atom
)