Dain, Jeff,
Thanks for your feedback on the weakness of the annotation approach.
It should be easy to have a less obtrusive configuration mechanism as
the logic is encapsulated within a single (AspectJ) aspect. I will
see what I can do.
In more details, an aspect adds the interface ClusteredStateMarker to
any classes having @ClusteredState:
declare parents:
(@ClusteredState *) implements ClusteredStateMarker;
It is easy to have a pattern driven mechanism instead, e.g.:
declare parents:
org.apache.xyz..* implements ClusteredStateMarker;
I now need to find a way to specify patterns outside of the aspect.
Regarding the WADI vs Tribes on Tomcat suggestion, there isn't yet a
Tomcat session manager integrated with WADI. BTW, WADI actually
relies on Tribes for its group communications thanks to Filip Hanik's
work on wadi-tribes.
Regarding a test with a bigger session size, I also would like to
know how wadi-aop performs. However, I would like to first resume
some Geronimo clustering work. Once done, I will touch base with
Jason as suggested to know if he can grant me access to GBuild in
order to conduct a real distributed test.
Thanks,
Gianny
On 19/10/2007, at 10:19 AM, Dain Sundstrom wrote:
I agree about the annotation thing. Would it be difficult change
the design to have some reasonable defaults, and only use
annotations (or xml) for overrides?
-dain
On Oct 18, 2007, at 3:49 PM, Jeff Genender wrote:
Gianni,
What you have done is very cool. I guess my only comment is that
what I
am reading is that the annotations force a lock to the clustering
engine, as opposed to being somewhat transparent by swapping out the
clustering manager.
Therefore, my application code needs these annotations coded as a
part
of it. In otherwords, in order for me to leverage the fine grained
capabilities of WADI, my application needs to be coded with the WADI
annotations. Did I read that correctly?
Regardless...its pretty cool stuff. We should talk about the
contract/interface for openejb...I look forward to working with
you ;-)
Jeff
