java work

AOP not useful for multiple cardinality (EJB example)

We have been working on a problem at work lately for which AOP might have looked like an interesting part of the solution. Actually it isn't...

Imagine that I wanted to be notified when a bean's state changes, including its references to other beans through CMR. Easy, you say : just define the right point cuts.

CMR fields with a many cardinality cannot be handled transparently because we would need to define point cuts on the Collection interface's add() and remove() method ! So we would end up calling the interceptor every where in the application where we use collections...

There are ways around this but they are all intrusive.

• wrapping the collection in a class we could define point cuts on for add() and remove()


• add methods to the EJB that add and remove objects to the collections and make these collections unavailable outside it to make sure developers don't use the collection to add and remove


• same as above only with an immutable collection


• defining the point cuts on the container's collection implementation (bad!)

Another issue with this is that I don't need to be notified on each individual setter method called on the bean. I'm content with being told "at the use case level", ie when all changes have been done and we want to commit to the persistant store.

Why don't you define pointcuts on the "use cases" I hear you cry ! Well, that's because the system wasn't architected around use cases and they aren't materialized well (we're working on it but it's still not there). It would also require tremendous discipline in order to never forget updating/adding point cuts when we refactor the code or add new functionality.

In the end ejbStore() seems more appropriate to us in this discovery phase...
Anybody else thought of this or seen similar problems ?