glassfish
  1. glassfish
  2. GLASSFISH-15775

Remote EJBs fail with ClassCastException in embeddable Glassfish

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1_b39
    • Fix Version/s: 3.1.1_b07 , 4.0
    • Component/s: embedded
    • Labels:
      None

      Description

      I think I've found a specification violation in the embeddable Glassfish project. My apologies if it turns out that this is not the case, but I've taken the liberty of setting the priority to Major because I don't see any wiggling out of this one.

      Here's what the specification has to say about business interfaces of stateless session beans in section 4.9.7:

      "If the business interface is a remote business interface, the argument and return values must be of valid types for RMI/IIOP. The remote business interface is not required or expected to be a java.rmi.Remote interface."

      My business interface is declared thusly:

      public interface AppealTypeManager extends DAO<Long, AppealType>

      { public Collection <? extends AppealType> findAllAppealTypes(final PagingControl pagingControl); }

      (Note the lack of @Remote, and the lack of "extends Remote".)

      My bean class is declared thusly:

      @Stateless//(name = "AppealTypeManager")
      @TransactionAttribute(TransactionAttributeType.REQUIRED)
      @Remote(AppealTypeManager.class)
      public class AppealTypeManagerBean extends AbstractDAO<Long, AppealType, AppealTypeEntity> implements AppealTypeManager

      { // ...etc. }

      I look up a reference to the remote business interface like this:

      final Context c = new InitialContext();
      final AppealTypeManager a = (AppealTypeManager)c.lookup("java:global/test-classes/AppealTypeManagerBean");

      When I deploy my EJB module to embeddable Glassfish, I get the following error upon lookup:

      javax.naming.NamingException: Lookup failed for 'java:global/test-classes/AppealTypeManagerBean' in SerialContext[myEnv=

      {java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming}

      [Root exception is javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]]
      at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:525)
      at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:455)
      at javax.naming.InitialContext.lookup(InitialContext.java:392)
      at javax.naming.InitialContext.lookup(InitialContext.java:392)
      at com.jenzabar.junit.ejb.dbunit.mem.GlassfishEmbeddedStrategy.getBean(GlassfishEmbeddedStrategy.java:126)
      at com.jenzabar.junit.ejb.dbunit.mem.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:98)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
      at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
      at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
      at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
      at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
      at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
      at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
      at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
      at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
      at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
      at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
      at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
      at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
      at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
      at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
      at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
      at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
      at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:145)
      at org.apache.maven.surefire.Surefire.run(Surefire.java:104)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
      at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017)
      Caused by: javax.naming.NamingException: ejb ref resolution error for remote business interfacecom.jenzabar.ngp.ia.designation.api.AppealTypeManager [Root exception is java.lang.ClassCastException]
      at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:434)
      at com.sun.ejb.containers.RemoteBusinessObjectFactory.getObjectInstance(RemoteBusinessObjectFactory.java:75)
      at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
      at com.sun.enterprise.naming.impl.SerialContext.getObjectInstance(SerialContext.java:559)
      at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:521)
      ... 34 more
      Caused by: java.lang.ClassCastException
      at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:262)
      at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:137)
      at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$12.read(DynamicMethodMarshallerImpl.java:353)
      at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.readResult(DynamicMethodMarshallerImpl.java:483)
      at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:203)
      at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
      at com.sun.corba.ee.impl.presentation.rmi.codegen.CodegenStubBase.invoke(CodegenStubBase.java:227)
      at com.sun.ejb.codegen._GenericEJBHome_Generated_DynamicStub.create(com/sun/ejb/codegen/_GenericEJBHome_Generated_DynamicStub.java)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at com.sun.ejb.EJBUtils.lookupRemote30BusinessObject(EJBUtils.java:422)
      ... 38 more
      Caused by: java.lang.ClassCastException: Object is not of remote type java.rmi.Remote
      at com.sun.corba.ee.impl.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:254)
      ... 50 more

      Again, the specification does not require a remote business interface to extend java.rmi.Remote, but it would appear that the Glassfish embedded runtime thinks it's necessary.

        Activity

        Hide
        Bhavanishankar added a comment -

        This seems to be an EJB container (or may be naming) issue. Hence re-categorizing.

        It can also be easily reproducible by running v2/appserv-tests/devtests/ejb/ejb31/embedded/remote

        Show
        Bhavanishankar added a comment - This seems to be an EJB container (or may be naming) issue. Hence re-categorizing. It can also be easily reproducible by running v2/appserv-tests/devtests/ejb/ejb31/embedded/remote
        Hide
        ljnelson added a comment - - edited

        This bug is present back through build 33; prior to that the API changed.

        (Of course it looks from the signature of the devtest you're talking about that this goes back to Glassfish 2?)

        "Forum" discussion here: http://www.java.net/forum/topic/glassfish/glassfish/glassfish-embedded-specification-violati

        Show
        ljnelson added a comment - - edited This bug is present back through build 33; prior to that the API changed. (Of course it looks from the signature of the devtest you're talking about that this goes back to Glassfish 2?) "Forum" discussion here: http://www.java.net/forum/topic/glassfish/glassfish/glassfish-embedded-specification-violati
        Hide
        ljnelson added a comment -

        This bug seems to have something to do with http://java.net/jira/browse/EMBEDDED_GLASSFISH-119, or rather both of them probably have the same underlying problem.

        It is my understanding that javax.ejb.embeddable.EJBContainer is under no obligation to support @Remote EJBs, and that org.glassfish.embeddable.* MUST (or at least is intended to) support @Remote EJBs.

        Show
        ljnelson added a comment - This bug seems to have something to do with http://java.net/jira/browse/EMBEDDED_GLASSFISH-119 , or rather both of them probably have the same underlying problem. It is my understanding that javax.ejb.embeddable.EJBContainer is under no obligation to support @Remote EJBs, and that org.glassfish.embeddable.* MUST (or at least is intended to) support @Remote EJBs.
        Hide
        marina vatkina added a comment - - edited

        Bhavani, please take a look: changes for rev 38343 & 38344 caused this regression. If you think that EJB container needs to adjust for these changes, it'd be helpful to know what it should be aware of. I do not see anything suspicious about the CLs used in the EJBUtils.lookupRemote30BusinessObject.

        Show
        marina vatkina added a comment - - edited Bhavani, please take a look: changes for rev 38343 & 38344 caused this regression. If you think that EJB container needs to adjust for these changes, it'd be helpful to know what it should be aware of. I do not see anything suspicious about the CLs used in the EJBUtils.lookupRemote30BusinessObject.
        Hide
        Bhavanishankar added a comment -

        Marina, the change revs you are referring to seem like the changes related to OSGi.
        IMO that can not be the cause for this. Why do you think otherwise?

        Show
        Bhavanishankar added a comment - Marina, the change revs you are referring to seem like the changes related to OSGi. IMO that can not be the cause for this. Why do you think otherwise?
        Hide
        marina vatkina added a comment -

        Bhavani, ejb31/embedded/remote passes with rev 38342 and fails with the ClassCastException: Object is not of remote type java.rmi.Remote with rev 38344.

        Show
        marina vatkina added a comment - Bhavani, ejb31/embedded/remote passes with rev 38342 and fails with the ClassCastException: Object is not of remote type java.rmi.Remote with rev 38344.
        Hide
        Nazrul added a comment -

        Since this did not make it into RC2, excluding from 3.1 count.

        Show
        Nazrul added a comment - Since this did not make it into RC2, excluding from 3.1 count.
        Hide
        Sanjeeb Sahoo added a comment -

        This is a Thread context class loader issue. GlassFish.start() sets the context class loader to an internal class loader and forgets to reset it after the call is complete. This is why user's classes can no longer be loaded using the context class loader in the thread that starts the server. Bhavani & I have discussed this and it will be addressed soon.

        "A possible work around is to set the context class loader before looking up the remote EJB." e.g.,

        GlassFish gf = GlassFishRuntime.bootstrap().newGlassFish();
        gf.start();
        gf.getDeployer().deploy(myapp);
        ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
        try

        { Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); new InitialContext().lookup(myEJB); }

        finally

        { Thread.currentThread().setContextClassLoader(oldCl); }
        Show
        Sanjeeb Sahoo added a comment - This is a Thread context class loader issue. GlassFish.start() sets the context class loader to an internal class loader and forgets to reset it after the call is complete. This is why user's classes can no longer be loaded using the context class loader in the thread that starts the server. Bhavani & I have discussed this and it will be addressed soon. "A possible work around is to set the context class loader before looking up the remote EJB." e.g., GlassFish gf = GlassFishRuntime.bootstrap().newGlassFish(); gf.start(); gf.getDeployer().deploy(myapp); ClassLoader oldCl = Thread.currentThread().getContextClassLoader(); try { Thread.currentThread().setContextClassLoader(getClass().getClassLoader()); new InitialContext().lookup(myEJB); } finally { Thread.currentThread().setContextClassLoader(oldCl); }
        Hide
        Bhavanishankar added a comment -

        Just added a devtest under v3/tests/embedded/ejb/remoteejb which follows the workaround.

        Show
        Bhavanishankar added a comment - Just added a devtest under v3/tests/embedded/ejb/remoteejb which follows the workaround.
        Hide
        Scott Fordin added a comment -

        Need more info to add issue to 3.1 Release Notes.

        Show
        Scott Fordin added a comment - Need more info to add issue to 3.1 Release Notes.
        Hide
        Scott Fordin added a comment -

        Does this still need to be included in the 3.1 Release Notes? If so, I need more information.

        Show
        Scott Fordin added a comment - Does this still need to be included in the 3.1 Release Notes? If so, I need more information.
        Hide
        Scott Fordin added a comment -

        Went with what information I had. Added issue to 3.1 Known Issues section of 3.1-3.1.1 Release Notes.

        Show
        Scott Fordin added a comment - Went with what information I had. Added issue to 3.1 Known Issues section of 3.1-3.1.1 Release Notes.
        Hide
        Bhavanishankar added a comment -

        Why fix this issue in 3.1.1?

        > This is issue that is directly reported by community.

        Which is the targeted build of 3.1.1 for this fix?

        > b07

        Do regression tests exist for this issue?

        > Yes – embedded devtests/fidelity tests.

        Which tests should QA (re)run to verify the fix did not destabilize GlassFish?

        > Regular QA tests should be run. No new test is required. Embedded devtest will take care of verifying the fix.

        Show
        Bhavanishankar added a comment - Why fix this issue in 3.1.1? > This is issue that is directly reported by community. Which is the targeted build of 3.1.1 for this fix? > b07 Do regression tests exist for this issue? > Yes – embedded devtests/fidelity tests. Which tests should QA (re)run to verify the fix did not destabilize GlassFish? > Regular QA tests should be run. No new test is required. Embedded devtest will take care of verifying the fix.
        Hide
        Bhavanishankar added a comment -

        Adding 3.2 also as the fixVersion

        Show
        Bhavanishankar added a comment - Adding 3.2 also as the fixVersion
        Hide
        vasilievip added a comment - - edited

        Bug still exists on GF 3.1.1, please reopen.
        Please find attached testcase.

        Show
        vasilievip added a comment - - edited Bug still exists on GF 3.1.1, please reopen. Please find attached testcase.
        Hide
        jyrkip added a comment -

        Happens on embedded 4.0 too.

        Show
        jyrkip added a comment - Happens on embedded 4.0 too.

          People

          • Assignee:
            Bhavanishankar
            Reporter:
            ljnelson
          • Votes:
            13 Vote for this issue
            Watchers:
            15 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: