4 Replies Latest reply on Dec 2, 2016 7:50 AM by Paul Ferraro

    Transparent deployment for Cluster and Standalone modes

    Clemens August Newbie

      Hello,

       

      we deploy an EAR file with session beans in Wildfly 9.0.2. We support standalone and cluster installations. At one point, I have found no way to support both modes transparently. The problem is with the group system (org.wildfly.clustering.group).

       

      We do the group lookup with

       

           @Resource(lookup = "java:jboss/clustering/group/default")

           private Group group;

       

      This works fine in clustered mode. In standalone mode, the resource injection does not work. Anyway, going by a simple JNDI lookup on "java:jboss/clustering/group/default" does not work, either, as it always returns null, in clustered mode, too.

       

      For our logic it would be appropriate to get a null value for group in standalone mode. As it works only with a resource injection (i.e., deployment fails in standalone), up to now it seems, that we need different builds for cluster and standalone mode.

       

      I tried injecting a Group as a @Resource into a CDI bean in order to activate it at runtime (after deployment) and then decide, whether I am in cluster mode, but the CDI bean could not be instantiated due to a "Service not started" - error.

       

      Thus my question: is there a way to transparently look up the cluster group (or the org.wildfly.clustering.dispatcher.CommandDispatcherFactory) in a way, that would return null in standalone mode and the actual objects in cluster mode and be deployable in both standalone and cluster mode?

       

      Thank you for your time and input in advance.

       

      Clemens

        • 1. Re: Transparent deployment for Cluster and Standalone modes
          Clemens August Newbie

          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.

          • 3. Re: Transparent deployment for Cluster and Standalone modes
            Clemens August Newbie

            Hello Paul

             

            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.

             

            1. 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?
            2. 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.

             

            Best regards

            Clemens

            • 4. Re: Transparent deployment for Cluster and Standalone modes
              Paul Ferraro Master

              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.