Prologue
This post intents to point out some pitfalls when using spring aop and reflection on the same objects. Moreover, it provides some examples of these pitfalls when combining ServiceMix & Camel with Spring JPA/Hibernate.
The two most common uses of aspect oriented programming with spring are:
- Security
- Transation Handling
I found myself having issues when applying those 2 on beans that are accessed using reflection (not in all cases) and below I am going to dig into those issues.
Prologue
This is the first from a series of posts that demonstrate how to extend ServiceMix management using Spring’s jmx and aop features. The version of SerivceMix that is going to be used will be 3.3.3-SNAPSHOT but I’ve been using this technique since 3.3 and it will probably can be applied to 4.x.
Problem
One of the most common problems I had with servicemix was that even the most simple changes in the configuration (e.g. changing the name of the destination in a jms endpoint) required editing the xbean.xml of the service unit and redeployment. Moreover this affected the rest of the service units contained in the service assemblies, which would be restarted too.
In the previous post Extend ServiceMix Management features using Spring – Part 1 I demonstrated a very simple technique that allows you to expose endpoint lifecycle operations via jmx. Now I am going to take it one step further and expose the endpoint configuration via jmx.
If you haven’t done already please catch up by reading Part 1.
Part II: Modifying the configuration of a live endpoint
I am going to use the wsdl-first servicemix sample as modified in the previous post and expose the property locationURI of the HttpEndpoint to jmx using Spring’s @ManagedAttribute annotation.
In the previous post Extend ServiceMix Management features using Spring – Part 2 I demonstrated how to use spring to gain control over endpoint lifecycle and configuration via jmx. You might wonder till now “what happens to those custom changes if I have to redeploy the assembly, restart servicemix or even worse restart the server?”. The short answer is that these changes are lost. The long answer is in this blog post, which explains how to persist those changes and how to make the endpoint reload them each time it starts.
Prologue
This is the first from a series of posts that demonstrate how to extend ServiceMix management using Spring’s jmx and aop features. The version of SerivceMix that is going to be used will be 3.3.3-SNAPSHOT but I’ve been using this technique since 3.3 and it will probably can be applied to 4.x.Problem
One of the most common problems I had with servicemix was that even the most simple changes in the configuration _(e.g. changing the name of the destination in a jms endpoint) _required editing the xbean.xml of the service unit and redeployment. Moreover this affected the rest of the service units contained in the service assemblies, which would be restarted too.