I have found a viable solution: pack a minimal EAR with 1 session bean, which contains the injection as mentioned above:
@Resource(lookup = "java:jboss/clustering/group/default")
private Group group;
This EAR is deployed only in a cluster installation. In all other places, the Group now can be fetched by a JNDI lookup. In a standalone installation the lookup will fail, and null can be returned.
Thank you very much for your answer. I would just like to make clear, what it is related to, because there was a reply by me already. So please allow me to follow up with 2 questions.
- Do you mean, that as of WF10.1, I can inject an org.wildfly.clustering.group.Group as a @Resource into a session bean, and it will work in standalone as well, giving a null value for the Group?
- Further on, can you confirm, that in WF9.0.2 this behaves differently, i.e., deployment of such a bean will fail in standalone mode?
I am asking, because for the time being we have to stay with WF9.0.2, and I would like to understand, whether I missed something by introducing the workaround described in my own reply.
clemens_august In WF10, all "default" clustering abstractions (including Group) will resolve to a local implementation when using a non-clustered server configuration. The local implementation of Group only has a membership of itself, and can never receive membership change events. I think this is more graceful than resolving to null.
These local implementations existed in WF9, but they used a separate JNDI name, e.g. java:jboss/clustering/group/local
So, the only way to make this transparent to your application was to externalize the absolute JNDI names to a deployment descriptor, and reference the clustering resources via their resource-ref names.