5 Replies Latest reply on Feb 14, 2011 4:08 AM by henk53

    Communication between JBoss AS 5 and JBoss AS 6

    atijms

      We have an application which is deployed on JBoss AS 6.0. A client for this application server runs on JBoss AS 5.1.

       

      Since JBoss AS 5.1 uses "Jboss Messaging" as JMS provider and JBoss AS 6.0 uses "Hornetq", I wonder if they can work together as client and server.

       

      I have tried to make them running together, adding missing jars to the client based on various exceptions I encountered, but I ended up in jar version conflicts. For instance, I got the following exception:

       

      Caused by: java.lang.NoSuchMethodException: org.jboss.deployment.security.EjbJaccPolicy.<init>(java.lang.String, org.jboss.metadata.ejb.jboss.JBossMetaData, java.lang.Boolean)
      

       

      So my question is: is it at all possible to do remote JNDI lookups between JBoss AS 5.1 and JBoss AS 6.0, and if so is it possible to post messages to a remote HornetQ queue from JBoss AS 5.1?

        • 1. Communication between JBoss AS 5 and JBoss AS 6
          wolfc

          It'll only work if you call the other server from within an isolated environment.

           

          See http://wolf-71.blogspot.com/2010/02/et-phone-home.html

          • 2. Communication between JBoss AS 5 and JBoss AS 6
            atijms

            Interesting!

             

            It looks a little tricky, but I'll give it a try. Thanks for the pointer.

             

            As a related question, is there any work going on within JBoss to make this a little bit more straightforward?

             

            Even when simply using a Java SE client, I found the JBoss AS client drivers are a bit unwieldy. Idealistically there would be a single small jar called jbossas-6.0.jndi.jar, that could be used in either Java SE, another JBoss AS version or another Java EE AS.

            • 3. Communication between JBoss AS 5 and JBoss AS 6
              atijms

              p.s. just wondering, where is the following deployer from the alunite project used for:

               

              https://github.com/wolfc/jboss-alunite/blob/master/deployer/src/main/java/org/jboss/alunite/deployer/Deployer.java

               

              The blog also mentions this:

               

              As Jaikiran correctly pointed out, the current bean proxy needs to be called within the correct context class loader. So we would also need a specialized external context which return wrappers to allow setting the thread context class loader at the right moment.

               

              Was this specialized external context ever created? Was this really necessary? The following comment seems to suggest it works, but there is no reference to this special context: http://community.jboss.org/message/569459#569459

              • 4. Re: Communication between JBoss AS 5 and JBoss AS 6
                atijms

                I created a new dynamic web project for JBoss AS 6 and added the AluniteClassLoader to this project just by copying the .java file.

                 

                Using the following code inside a Singleton EJB bean, I get an exception however:

                 

                 

                    URL[] urls = new URL[2];        
                        urls[0] = new URL("file:///opt/jboss/client/jbossall-client.jar");
                
                        URLClassLoader urlCl = new URLClassLoader(urls, null);
                        ClassLoader cl = new AluniteClassLoader(urlCl, ClassLoader.getSystemClassLoader());
                        ClassLoader previous = Thread.currentThread().getContextClassLoader();
                        Thread.currentThread().setContextClassLoader(cl);
                        try {
                            String providerUrl = "jnp://localhost:1199";
                            Properties properties = new Properties();
                            properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
                            properties.put(Context.URL_PKG_PREFIXES, "jboss.naming:org.jnp.interfaces");
                            properties.put(Context.PROVIDER_URL, providerUrl);
                            InitialContext ic = new InitialContext(properties);
                
                            Object test = ic.lookup("abc");
                
                        } finally {
                            Thread.currentThread().setContextClassLoader(previous);
                        }
                

                 

                The exception is:

                 

                Caused by: java.lang.NullPointerException
                    at sun.net.util.URLUtil.urlNoFragString(URLUtil.java:29) [:1.6.0_23]
                    at sun.misc.URLClassPath.getLoader(URLClassPath.java:292) [:1.6.0_23]
                    at sun.misc.URLClassPath.access$000(URLClassPath.java:60) [:1.6.0_23]
                    at sun.misc.URLClassPath$1.next(URLClassPath.java:195) [:1.6.0_23]
                    at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:206) [:1.6.0_23]
                    at java.net.URLClassLoader$3$1.run(URLClassLoader.java:416) [:1.6.0_23]
                    at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23]
                    at java.net.URLClassLoader$3.next(URLClassLoader.java:413) [:1.6.0_23]
                    at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:438) [:1.6.0_23]
                    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:27) [:1.6.0_23]
                    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:36) [:1.6.0_23]
                    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:27) [:1.6.0_23]
                    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:36) [:1.6.0_23]
                    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:27) [:1.6.0_23]
                    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:36) [:1.6.0_23]
                    at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration$1.run(VersionHelper12.java:197) [:1.6.0_23]
                    at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_23]
                    at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.getNextElement(VersionHelper12.java:194) [:1.6.0_23]
                    at com.sun.naming.internal.VersionHelper12$InputStreamEnumeration.hasMore(VersionHelper12.java:214) [:1.6.0_23]
                    at com.sun.naming.internal.ResourceManager.getApplicationResources(ResourceManager.java:470) [:1.6.0_23]
                    at com.sun.naming.internal.ResourceManager.getInitialEnvironment(ResourceManager.java:159) [:1.6.0_23]
                    at javax.naming.InitialContext.init(InitialContext.java:219) [:1.6.0_23]
                    at javax.naming.InitialContext.<init>(InitialContext.java:197) [:1.6.0_23]
                

                 

                There is a JBoss AS 5.1 instance running at localhost:1199

                 

                Any idea?

                • 5. Communication between JBoss AS 5 and JBoss AS 6
                  henk53

                  As a related question, is there any work going on within JBoss to make this a little bit more straightforward?

                   

                  I wonder if this will ever get 'fixed'. EJB remote communication has come a long way. From being arcane and over complicated in the EJB1 and EJB2 days, to actually pretty convenient and straightforward these days as long as both ends are the exact same application server.

                   

                  If JNDI lookups were somehow to be standardized, it would be a major help.

                   

                  You would then however still run into problems when doing lookups for say a remote JMS queue (another important use-case for remote JNDI lookups). The thing is that there is no universal standard type that represents the remote queue, you need to have the exact type used by the remote server locally, even though it actually always comes down to this type just being a wrapper for a string or at most a string pair.