Emanuel Muckenhuber wrote:
In the end - I think if you configure clustering it would make sense to also deploy the needed service. Where you definitely should not care about which deployments are needed for this. Since we are going to have a domain specific model - each fragment could export a requirement on a module.
The tricky part about this is the "not care about which deployments are needed for this" bit. Well, thinking about it maybe not all that tricky. :) The clustering services come in 4 general "categories"
- Core capabilites (jgroups integration, infinispan integration)
- Remote access stuff (HAPartition for cluster-aware proxies, HA-JNDI). You don't know if this is needed as the requirement comes from
- an annotation on an unknown EJB in deploy/
- a completely unknown remote client that wants to use HA-JNDI
- HASingleton (which is just a different use case for HAPartition), no added services
- Misc odds and ends
So, a <cluster/> element itself implies a need for 1. A couple attributes on <cluster/>, default = true, could control 2 and 3. I'd have to look more closely at the 4 stuff, but I suspect it's either so lightweight we just include it if 2 or 3 are needed, or we can detect the need for it from what other capabilities are required.
So, yeah, using <cluster/> as a trigger to add some extra capabilities sounds good.