7 Replies Latest reply on Feb 25, 2013 4:52 PM by rich.vibeskowski

    HornetQ 2.3 in JBoss4?

    mlange

      I stumbled upon this integration problem when trying to use a 2.3 client inside JBoss4:

       

      java.lang.NoSuchMethodError: org.jboss.logging.Logger.getMessageLogger(Ljava/lang/Class;Ljava/lang/String;)Ljava/lang/Object;

       

      The reason is that 2.3 uses the new JBoss Logging while there is already a org.jboss.logging.Logger implementation in jboss-common.jar. What is the preferred workaround for that? Scoping the client's classloader is not a suitable option since the client has several archives which need access to the HornetQ classes (deployed as a resource adaptor).

       

      Thanks,

      Marek

        • 1. Re: HornetQ 2.3 in JBoss4?
          jbertram

          Once 2.3.0.Final is out old clients will be fully compatible with 2.3 so there will be no real need to upgrade them unless you want to leverage the new JGroups client discovery option (as opposed to the traditional UDP discovery already available).

          • 2. Re: HornetQ 2.3 in JBoss4?
            clebert.suconic

            He's talking about HornetQ inside JBoss4. I don't think that's going to happen. you would need to change lots of things on JBoss 4 (logger for instance) to make it happen.

             

            Anyone is welcomed to do the work on integration, but I honestly don't want to support hornetq 2.3 on JBoss4.. it's too old and hard to maintain.

            • 3. Re: HornetQ 2.3 in JBoss4?
              jbertram

              Even HornetQ clients within JBoss 4/5/6 will have this problem.  There are class names which overlap in the version of JBoss Logging which the AS uses and the new version which the HornetQ client code uses.

               

              To be clear, I got around this problem when deploying the HornetQ 2.3 JCA RA in JBoss AS 5 by packaging the RA in an EAR and then isolating the EAR's classloader.

              • 4. Re: HornetQ 2.3 in JBoss4?
                mlange
                To be clear, I got around this problem when deploying the HornetQ 2.3 JCA RA in JBoss AS 5 by packaging the RA in an EAR and then isolating the EAR's classloader.

                It seems to be the only way to get around this. Otherwise the Logger class is loaded from the UCL first.

                 

                "but I honestly don't want to support hornetq 2.3 on JBoss4.. it's too old and hard to maintain."

                 

                Isn't the same problem there on JBoss5 and 6? Think of migrations scenarios. It is almost impossible to migrate older JBoss versions to JBoss7 from one day to another...I just want to raise awareness for these vaild use cases. 2.3 clients cannot be used (at least in JBoss4) without further classloading knowledge. It should be documented at least somewhere.

                 

                Marek

                • 5. Re: HornetQ 2.3 in JBoss4?
                  clebert.suconic

                  You can use 2.2 clients on 2.3.Beta3+ servers. Maybe that would solve it?

                  1 of 1 people found this helpful
                  • 6. Re: HornetQ 2.3 in JBoss4?
                    mlange

                    You can use 2.2 clients on 2.3.Beta3+ servers. Maybe that would solve it?

                     

                    Of course this would make it easier esp. on the resource adaptor client. It should be documented when the compatibility was introduced in 2.3.Beta3 upwards. Thanks.

                    • 7. Re: HornetQ 2.3 in JBoss4?
                      rich.vibeskowski

                      FWIW I did some testing using the 2.2.14 client libs [from JBoss 4] against 2.3.CR1. Everything seemed to work fine except replication. During failback, we saw message duplication.

                      Testing with a non-Jboss application, we could reproduce the message duplication with the 2.2.14 client libs.

                      The duplication did not occur when using the 2.3.CR1 client libs.

                      So anybody trying this out should test thoroughly