Discussion:
[jboss-user] [EJB3] - Problems using the @RemoteHome annotation for backward compatibility
Mike Miller
2013-02-26 22:29:24 UTC
Permalink
Mike Miller [https://community.jboss.org/people/mikemil] created the discussion

"Problems using the @RemoteHome annotation for backward compatibility"

To view the discussion, visit: https://community.jboss.org/message/799738#799738

--------------------------------------------------------------
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.  
--------------------------------------------------------------

Reply to this message by going to Community
[https://community.jboss.org/message/799738#799738]

Start a new discussion in EJB3 at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2029]
Mike Miller
2013-02-28 16:04:31 UTC
Permalink
Mike Miller [https://community.jboss.org/people/mikemil] created the discussion

"Re: Problems using the @RemoteHome annotation for backward compatibility"

To view the discussion, visit: https://community.jboss.org/message/800109#800109

--------------------------------------------------------------
Okay,

I am going to answer my own question.  Between the JBoss EJB3 tutorials download/classes and the following https://blogs.oracle.com/enterprisetechtips/entry/ejb_3_0_compatibility_and#saks 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.  
--------------------------------------------------------------

Reply to this message by going to Community
[https://community.jboss.org/message/800109#800109]

Start a new discussion in EJB3 at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2029]
Loading...