1 Reply Latest reply on Feb 28, 2013 11:04 AM by Mike Miller

    Problems using the @RemoteHome annotation for backward compatibility

    Mike Miller Newbie

      We are (hopefully) coming to the end of our migration from EJB 2.1 to EJB 3 "exercise".   We are encountering ClassCastExceptions when we try to load an EJB3 bean from one of our older, yet to be migrated EJB2.1 server instances.   If I understood the 3.0 spec correctly, 3.0 can be a 'client' of 2.1 but not really vise versa.  

       

      Little bit of history - our product is a POS where we have a 'store server' at each retail store and a 'Central' server at company headquarters.   This can NOT be big banged over night, so our migration/upgrade path means that Central will be upgraded to 3.0 first, then sets of stores will be upgraded, but not all at once. Most of the communication between servers is done thru JMS, but we do have some cases where we make what we call a 'reverse service call' which means a store loads an EJB from the Central Server's JNDI, or Central loads an EJB from the Store servers JNDI.  This is where we are at right now.  Central at 3.0 and Store at 2.1, then Store requests an EJB from Central and when we attempt to PortableNarrow - we get a ClassCastException.

       

      We are doing this on JBoss 4.2.3.GA.

       

       

      If I understand the documentation correctly, it sounds like we should be able to use the @RemoteHome to generate the home interface for the 2.1 clients to use to talk to our Central Server. I have tried this and assume that I am missing some piece of the puzzle.  I have tried to compare mine agains the ejb21_client_adaptors sample in the EJB3 tutorial files but it's not working.   The exception we get on the Store server side is below:

       

      {code}

      2013-02-26 13:33:00,985 ERROR [root] java.lang.RuntimeException: problem connecting to EJB container

        at com.jda.portfolio.infrastructure.base.service.ServiceFactory.getRemoteService(ServiceFactory.java:503)

        at com.jda.portfolio.infrastructure.base.service.ServiceFactory$CentralServerLookupThread.run(ServiceFactory.java:621)

       

       

      2013-02-26 13:33:00,989 ERROR [root] Caused by: null

      java.lang.ClassCastException

                at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:245)

                at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:153)

                at com.jda.portfolio.infrastructure.base.service.ServiceFactory.getRemoteService(ServiceFactory.java:488)

                at com.jda.portfolio.infrastructure.base.service.ServiceFactory$CentralServerLookupThread.run(ServiceFactory.java:621)

      Caused by: java.lang.ClassCastException: $Proxy1238 cannot be cast to org.omg.CORBA.Object

                at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:228)

                ... 3 more

      2013-02-26 13:33:00,991 ERROR [root] Root cause: $Proxy1238 cannot be cast to org.omg.CORBA.Object

      java.lang.ClassCastException: $Proxy1238 cannot be cast to org.omg.CORBA.Object

                at com.sun.corba.se.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:228)

                at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:153)

                at com.jda.portfolio.infrastructure.base.service.ServiceFactory.getRemoteService(ServiceFactory.java:488)

      {code}

       

      Below are snippets from our classes

       

      EJB3 Session Bean

      {code}

      package com.jda.portfolio.pos.server.service.security;

      ...

       

      @Stateless

      @RemoteHome(KeyManagementServiceHome.class)

      @RemoteBinding(jndiBinding="ejb/KeyManagementService")

      @LocalBinding(jndiBinding="ejb/KeyManagementServiceLocal")

      @TransactionManagement(TransactionManagementType.CONTAINER)

      @TransactionAttribute(TransactionAttributeType.REQUIRED)

      public class KeyManagementServiceBean extends com.jda.portfolio.infrastructure.server.service.AbstractService implements KeyManagementService, KeyManagementServiceLocal

      {

          @Init

          public void ejbCreate()  {

             System.out.println("**** ejbCreate() of " + this.getClass() + " called ****");

          }

       

      ...

      }

      {code}

       

      New Home interface for 2.1 clients

      {code}

      package com.jda.portfolio.pos.server.service.security;

      ...

      public interface KeyManagementServiceHome extends EJBHome {

       

                public KeyManagementServiceRemote create() throws CreateException, RemoteException;

      }

      {code}

       

      Remote interface created by Home

      {code}

      package com.jda.portfolio.pos.server.service.security;

      import javax.ejb.EJBObject;

       

      public interface KeyManagementServiceRemote extends EJBObject {

       

                   public int addKey( com.jda.portfolio.infrastructure.base.util.KeyGenData keyGenData ) ;

          public boolean publishKeys( java.util.List locationNumbers ) ;

        public int removeKeys( java.util.List keysToRemove ) ;

        }

      {code}

       

      Using no deployment descriptors.  After making this change, I did dump the JNDIView for my Central (3.0) server from the console and noticed one strange entry that does not show up in our other servers.  There is an entry that looks like a subcontext of "KeyManagementServiceBean" with a named pair of 'home' : $Proxy1256.   The KeyManagementServiceBean is actually the name of the class for the EJB Session bean I am trying to make available as a 2.1 bean.

       

      Setting breakpoints in the Store server where we are loading and attempting to narrow the reference - I also noticed that the class within the proxy class is usually 'ClientContainer' when things work, like for 2.1 - but when we load the 3.0 bean from Central, the class name in the proxy is StatelessRemoteProxy.  Not sure if that means anything or just a result of the different implementations.

       

      I know there's a lot of info here but I can help clarify it if it is not clear.  

        • 1. Re: Problems using the @RemoteHome annotation for backward compatibility
          Mike Miller Newbie

          Okay,

           

          I am going to answer my own question.  Between the JBoss EJB3 tutorials download/classes and the following blog posting, I was able to get my EJB 2.1 system to talk to the new EJB3.0 system.  Below are the hints/changes I had to make from above:

           

          1. I deleted the KeyManagementServiceRemote interface and replace any references to it with references to KeyManagementService, which is my EJB3.0 remote business interface.
          2. Add the @RemoteHomeBinding annotation to my service bean class (I think this was big) - so that now the home is bound to the (correct) name that the rest of the system uses by convention.

           

          This appears to be working the way is should.  The samples are generally pretty good, but our usage tends to be different because we can't always use the annotations, which help resolve some of these problems.  We have to go thru the JNDI lookup in some cases because we may be retrieving the service from a different server than where the ejb client is currently running on.  In this case, we were running on and old ejb 2.1 instance (Store) and need to retrieve data from the newer, ejb 3.0 Central Server - and no guarantees about when either the Central or Store servers would be upgraded.