Isn't this a version of Observer/Observable?
Except, as Bill says this should be implemented as a plain Introduction rather than
a Mixin, such that the advice holds the Subject's observers.
This would allow the pojo to dynamically become observable instead of
just at weave time.
Guess I have never seriously looked at this pattern under aop before. :-)
Anyway, currently it only notifies the observer that the Subject has changed. But it doesn't say what exactly is changed. For my case, I will
need to know whether it is a field read/write and possibly which one.
In addition, another requirement of mine is user transparency. That is a POJO writer should not need to bother with jboss-aop.xml declaration. In the case of Tomcat http session replication, I don't require a user to supply a jboss-aop.xml to put introduction in place.
Thirdly, I am using dynamic aop to insert the interceptor at runtime.
Do you think I still can fit these requirements into this aop pattern?
Thanks for the suggestion,
Your pattern is a generalization of the GOF pattern.
You might call it FineGrainedObservable
Just as Bill's aspect library document contains other extensions:
I would think that the others can be implemented from the FineGrainedObservable
simply by using different mixins for the Observer:
GOFObserver is only interested in the Subject regardless of the field.
TransactionalObserver enlists a synchronization to only fireChange if/when the transaction commits
AsyncObserver uses a queued threadpool to deliver the fireChange on a different thread
You should also be able mix them, e.g. TransactionAsyncObserver is really
TransactionObserver and AsyncObserver where the
Synchronization does a callback to invokeNext on the TransactionObserver
advice which invokes the Async processing to take the work off the thread
that is committing.
AsyncTransactionObserver which does the opposite would not be as useful
since you have a race with the commit() on the main thread, but you get the
In the dynamic case, you only need to insert the advice, you don't need
the interface on the front end since you know what wants to addObserver().
You are right. I need a FineGrainedObservable with a new Subject and Intecerptor that can send the specfic event (e.g., particular field get/set). But since I am interested in the dynamic case, I won't need Introduction declaration in the xml.
I will try it on my cache aop first.
instead of writing an observer/observable framework, instead, well-defined pointcuts should be published. Basically, what you do is define the pointcut expressions for each integration point in JBossCache and name them. Then anybody can do anything they want around these named pointcuts. They can write any observer/observable pattern they want.
This is a good suggestion. Is there a way to look up the named pointcuts dynamically?