1 Reply Latest reply on May 26, 2008 5:55 AM by spieper

    Jboss Version Compatibility

    spieper

      Hi,

      I want to make two different versions of jboss talk to each other. According to http://wiki.jboss.org/wiki/JBossVersionCompatibilityMatrix I should be able to do what I want:

      I have a legacy ejb 2.x application deployed on a jboss 4.0.2 and I have a newly developed ejb3 application deployed on a jboss 4.2.0.

      The calls from 4.2.0 to 4.0.2 work fine.

      But the calls from the 4.0.2 => 4.2.0 direction run into trouble.

      The ejb3 application offers a @RemoteHome interface for the legacy application as described here
      http://java.sun.com/mailers/techtips/enterprise/2007/TechTips_Feb07.html#1

      Yet the lookup of the home interface in the legacy application fails with a ClassNotFoundException because the ProxyFactory creates an ejb3 specific proxy object:

      javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.ejb3.stateless.StatelessRemoteProxy (no security manager: RMI class loader disabled)]
       at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:713)
       at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
      


      The compatibility matrix I referred to above states that I "must use the legacy rmi invokers" to make this work. I have found no further documentation what these invokers are and how I configure my application to use them.

      What I have found are invoker-proxy-binding definitions in the standardjboss.xml deployed in my 4.2.0 jboss. There is for example:

       <invoker-proxy-binding>
       <name>stateless-rmi-invoker</name>
       <invoker-mbean>jboss:service=invoker,type=unified</invoker-mbean>
       <proxy-factory>org.jboss.proxy.ejb.ProxyFactory</proxy-factory>
       .....
      


      Is this the right place to look for some reconfiguration? How would I need to change this for my application and how would I make the ProxyFactory return non-ejb3 specific proxy objects?

      I would be grateful for any hint in finding a solution for this, as I do not have the option of simply plugging some ejb3 classes into the 4.0.2 jboss.


      Bye
      S.Pieper

        • 1. Re: Jboss Version Compatibility
          spieper

          Hi,

          we have by now managed to find a work around, though we are still looking for a more elegant solution.

          So here is a short description of our current solution:

          We have now deployed a proxy application to the 4.2.0 server from which we have removed all annotations and which is configured with the following jboss.xml (and included in the ear):

          <jboss>
           <enterprise-beans>
           <session>
           <ejb-name>RmiProxy</ejb-name>
           <jndi-name>ejb/remote/RmiProxy</jndi-name>
           <invoker-bindings>
           <invoker>
          
          <invoker-proxy-binding-name>stateless-rmi-invoker</invoker-proxy-binding-name>
           </invoker>
           </invoker-bindings>
           </session>
           </enterprise-beans>
          </jboss>
          


          Since there are no annotations, this application does not trigger the ejb3.deployer and is instead deployed as 2.x application in the 4.2.0 jboss.

          This proxy application is also configured to use the legacy rmi invoker.

          Now the 2.x client which is deployed in the 4.0.2 server can make 2.x style calls to the proxy which is deployed in the 4.2.0 server. The proxy application can then make rmi calls to the ejb3 application deployed in the same 4.2.0 server.

          This eliminates the problem with the 4.0.2 server not knowing the org.jboss.ejb3.stateless.StatelessRemoteProxy as the proxy application is running in a server that has the class and is itself configured as 2.x application which does not return ejb3 style rmi proxy objects.

          We're now looking for a way to eliminate the need for a proxy application.

          We may in the future simply try to upgrade the jboss on which the legacy application is running to remove this problem completely.

          Bye
          SPieper