1 2 Previous Next 21 Replies Latest reply on Aug 21, 2008 12:24 PM by Andrew Rubinger

    EJBTHREE-1423 Test case for @RemoteBinding

    Andrew Rubinger Master

      Posting for Jaikiran, who was having some troubles with the Forum earlier:

      "jaikiran" wrote:

      I see that Ales has committed the changes to http://jira.jboss.com/jira/browse/JBMETA-45. With this, i can now bring EJBTHREE-1423 to a completion. Just a couple of question regarding this:

      1) I see that the fix for JBMETA-45 is in version 1.0.0.Beta27. I updated my EJB3 local repository and did a "clean install". However the 1.0.0Beta27 of jboss-metadata was not downloaded. I then added a version attribute to the pom.xml in the "proxy" module, to force the download (just for my local testing):

      <dependency>
      <groupId>org.jboss.metadata</groupId>
      <artifactId>jboss-metadata</artifactId>
      <version>1.0.0.Beta27</version>
      </dependency>

      This successfully downloaded the Beta27 of jboss-metadata.

      How are these dependency managed in general? Does someone decide which Beta to use and then update (one central) pom?


      S,
      ALR

        • 1. Re: EJBTHREE-1423 Test case for @RemoteBinding
          Andrew Rubinger Master

          Except where only required by a single EJB3 Module, we've put the dependencies into EJB3 Build POM's "dependencyManagement" section, where the version and scope may be inherited by sub-modules. You'll still need to put the groupId and artifactId into "Proxy", but the version will be set by EJB3 Build.

          One caveat: Ensure EJB3 Proxy has a parent of the correct EJB3 Build SNAPSHOT that you've changed.

          In general, we'd like to keep the versions closely aligned with those used by the AS Component Matrix (repos/jbossas/trunk/component-matrix/pom.xml) such that we compile/test against same versions used in the AS runtime, but we currently have no shared contract. This was an issue of some debate awhile back:

          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131748

          S,
          ALR

          • 3. Re: EJBTHREE-1423 Test case for @RemoteBinding
            jaikiran pai Master

            The testcase fails on 1.0.0.Beta27 of JBossMetadata. The test includes:

            1) Ensure that the @RemoteBinding is picked up and the corresponding RemoteBindingMetaData is created an stored in the JBossSessionBeanMetaData. --> This passes

            2) Ensure that the bean is bound to the jndi-name specified in the RemoteBindingMetaData. --> This fails.


            Here's the bean definition:

            @Stateless
            @Remote (MyStatelessRemote.class)
            @Local (MyStatelessLocal.class)
            @RemoteBinding (jndiBinding="SomeRemoteName")
            public class MyStatelessBeanWithBindings implements MyStatelessLocal, MyStatelessRemote
            {
            
            ...
            
            }
            


            Here's the relevant part from the test case:

            @Test
             public void testRemoteBinding() throws Throwable
             {
             // create the bean
             SessionContainer sessionContainer = Utils.createSlsb(MyStatelessBeanWithBindings.class);
            
             // bind it to JNDI
             Ejb3RegistrarLocator.locateRegistrar().bind(sessionContainer.getName(), sessionContainer);
            
             List<RemoteBindingMetaData> remoteBindingsMetadata = sessionContainer.getMetaData().getRemoteBindings();
            
             assertNotNull("No RemoteBindingMetadata available", remoteBindingsMetadata);
             // make sure that the remotebinding metadata list has 1 @RemoteBinding information
             assertEquals("RemoteBindingMetadata does not have any RemoteBinding information available", remoteBindingsMetadata.size(), 1);
            
            
             // Ensure that the RemoteBindingMetaData is created properly with the specified jndiBinding name.
             Iterator<RemoteBindingMetaData> remoteBindingsMetadataIterator = remoteBindingsMetadata.iterator();
             RemoteBindingMetaData remoteBindingMetadata = remoteBindingsMetadataIterator.next();
            
             assertEquals("RemoteBinding JNDI name does not match SomeRemoteName", "SomeRemoteName", remoteBindingMetadata.getJndiName());
            
             // Now ensure that the RemoteBindingMetaData is used for binding the
             // remote interface of the bean.
             Context ctx = new InitialContext();
             Object remoteBean = ctx.lookup(remoteBindingMetadata.getJndiName());
            
             assertNotNull("Remote bean returned from JNDI lookup for jndi-name " + remoteBindingMetadata.getJndiName() + " is null");
            
             assertTrue("Remote bean returned from JNDI lookup is NOT an instance of " + MyStatelessRemote.class, (remoteBean instanceof MyStatelessRemote)); ---> This fails. The jndi object returned is org.jnp.interfaces.NamingContext@145e2d5
            
             }
            


            Upon some debugging, i observed that the org.jboss.metadata.ejb.jboss.JBossSessionPolicyDecorator.determineJndiName returns an incorrect jndi-name:

            16:40:47,623 INFO [MetaDataHelper] Business Remote JNDI Name: SomeRemoteName/remote
            16:40:47,639 INFO [MetaDataHelper] Business Remote JNDI Name for org.jboss.ejb3.test.proxy.common.ejb.slsb.MyStatelessRemote: SomeRemoteName/remote-org.jboss.ejb3.test.proxy.common.ejb.slsb.MyStatelessRemote
            16:40:47,639 INFO [MetaDataHelper] Local JNDI Name: SomeRemoteName/local
            16:40:47,639 INFO [MetaDataHelper] Business Local JNDI Name for org.jboss.ejb3.test.proxy.common.ejb.slsb.MyStatelessLocal: SomeRemoteName/local-org.jboss.ejb3.test.proxy.common.ejb.slsb.MyStatelessLocal
            


            As a result, the bean gets bound to SomeRemoteName/remote instead of SomeRemoteName.







            • 4. Re: EJBTHREE-1423 Test case for @RemoteBinding
              jaikiran pai Master

              By the way, the @LocalBinding/@LocalHomeBinding/@RemoteHomeBinding are working fine.

              Do you want me to open a JIRA in JBossMetadata for tracking the @RemoteBinding issue?

              • 5. Re: EJBTHREE-1423 Test case for @RemoteBinding
                Andrew Rubinger Master

                Are you still seeing issues here, using jboss-metadata 1.0.0.Beta32?

                S,
                ALR

                • 6. Re: EJBTHREE-1423 Test case for @RemoteBinding
                  jaikiran pai Master

                  I will run that test case with Beta32 and let you know.

                  • 7. Re: EJBTHREE-1423 Test case for @RemoteBinding
                    jaikiran pai Master

                    Andrew,

                    With jboss-metadata 1.0.0.Beta32, the @RemoteBinding test case passes. But the @LocalHomeBinding is not being honoured resulting in a couple of failing test cases. I have attached a patch and logs to EJBTHREE-1423, which has the failing testcases. Let me know if you need more details or if you have any review comments.

                    • 8. Re: EJBTHREE-1423 Test case for @RemoteBinding
                      Andrew Rubinger Master

                      Good job, you've exposed https://jira.jboss.org/jira/browse/JBMETA-91, which I'll get into the next release (1.0.0.Beta36) this weekend assuming no regression in other dependent testsuites.

                      Using current SNAPSHOT of jboss-metadata, I've now got all these tests passing locally.

                      Some change requests to your patch (mostly housekeeping):

                      * build/pom.xml .. let's keep that out of scope. I've updated the jboss-metadata dependency in SVN.
                      * Add to setupBeforeClass the boilerplate for deploying *-aop.xml, example in JndiSessionRegistrarTestCaseBase (else tests will fail)
                      * Add tests that the explicit addresses are also unbound upon undeploy

                      Also, the package name / class name of the test could be more in-line with those you've done for JndiSessionRegistrarTestCaseBase; they both test pretty much the same thing, only difference is that this new one uses explicit bindings as opposed to the default. Maybe they could be merged? I'd just like it to be ultra-clear what these tests do from their names alone (JndiSessionRegistrarTestCaseBase sounds pretty vauge). Open to your suggestions here and then we'll move things around to be friendlier.

                      S,
                      ALR

                      • 9. Re: EJBTHREE-1423 Test case for @RemoteBinding
                        Emanuel Muckenhuber Master

                         

                        "ALRubinger" wrote:
                        which I'll get into the next release (1.0.0.Beta36) this weekend assuming no regression in other dependent testsuites.

                        cool, but it would be good to sync up on the next metadata release, because i might have a similar fix and i'm not quite sure if the recent changes i did to metadata would work out of the box without the changes i have locally to AS trunk ;)

                        • 10. Re: EJBTHREE-1423 Test case for @RemoteBinding
                          Andrew Rubinger Master

                           

                          "emuckenhuber" wrote:
                          cool, but it would be good to sync up on the next metadata release


                          OK, I don't think my next release of EJB3 Core is dependent upon this issue or a new metadata release. Wherever possible I'd rather have you guys manage jboss-metadata anyway. :)

                          So Jaikiran, please hold off on committing these tests to EJB3 Proxy until jboss-metadata 1.0.0.Beta36 is out.

                          S,
                          ALR

                          • 11. Re: EJBTHREE-1423 Test case for @RemoteBinding
                            jaikiran pai Master

                             

                            "ALRubinger" wrote:

                            So Jaikiran, please hold off on committing these tests to EJB3 Proxy until jboss-metadata 1.0.0.Beta36 is out.



                            Okay.

                            • 12. Re: EJBTHREE-1423 Test case for @RemoteBinding
                              Andrew Rubinger Master

                              Jaikiran:

                              jboss-metadata 1.0.0.Beta36 is out, so commit those tests at your convenience (they should pass)

                              S,
                              ALR

                              • 13. Re: EJBTHREE-1423 Test case for @RemoteBinding
                                jaikiran pai Master

                                Andrew,

                                I tested this with jboss-metadata 1.0.0.Beta36. My test cases which work on Remote beans are failing. The ones working with Local beans pass. Here's the exception, i see for all my remote bean test cases:

                                testRemoteBindingForSlsb(org.jboss.ejb3.test.proxy.binding.unit.JNDIBindingTestCase) Time elapsed: 1.016 sec <<< ERROR!
                                javax.naming.NamingException: Could not dereference object [Root exception is java.lang.RuntimeException: Could not create the EJB3 Business Proxy implementing "org.jboss.ejb3.test.proxy.common.ejb.slsb.MyStatelessRemote" for MyStatelessBeanWithBindings]
                                 at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1337)
                                 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:765)
                                 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:629)
                                 at javax.naming.InitialContext.lookup(InitialContext.java:351)
                                 at org.jboss.ejb3.test.proxy.binding.unit.JNDIBindingTestCase.testRemoteBindingForSlsb(JNDIBindingTestCase.java:184)
                                 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:585)
                                 at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
                                 at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
                                 at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
                                 at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
                                 at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
                                 at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
                                 at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
                                 at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
                                 at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
                                 at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
                                 at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
                                 at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
                                 at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
                                 at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
                                 at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
                                 at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
                                 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:585)
                                 at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
                                 at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:993)
                                Caused by: java.lang.RuntimeException: Could not create the EJB3 Business Proxy implementing "org.jboss.ejb3.test.proxy.common.ejb.slsb.MyStatelessRemote" for MyStatelessBeanWithBindings
                                 at org.jboss.ejb3.proxy.factory.session.SessionProxyFactoryBase.createProxyBusiness(SessionProxyFactoryBase.java:235)
                                 at org.jboss.ejb3.proxy.objectfactory.session.SessionProxyObjectFactory.createProxy(SessionProxyObjectFactory.java:129)
                                 at org.jboss.ejb3.proxy.objectfactory.session.stateless.StatelessSessionProxyObjectFactory.getProxy(StatelessSessionProxyObjectFactory.java:79)
                                 at org.jboss.ejb3.proxy.objectfactory.ProxyObjectFactory.getObjectInstance(ProxyObjectFactory.java:161)
                                 at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
                                 at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1312)
                                 at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1329)
                                 ... 30 more
                                Caused by: java.lang.AssertionError: Could not find Advice Stack with name: StatelessSessionClientInterceptors
                                 at org.jboss.ejb3.proxy.factory.ProxyFactoryBase.getInterceptors(ProxyFactoryBase.java:185)
                                 at org.jboss.ejb3.proxy.factory.session.stateless.StatelessSessionRemoteProxyFactory.createInvocationHandler(StatelessSessionRemoteProxyFactory.java:147)
                                 at org.jboss.ejb3.proxy.factory.session.SessionProxyFactoryBase.createProxyBusiness(SessionProxyFactoryBase.java:227)
                                 ... 36 more


                                And this exception happens when i lookup the bean using the remote jndi name:

                                
                                 @Test
                                 public void testRemoteBindingForSlsb() throws Throwable
                                 {
                                 // create the bean
                                 this.sessionContainer = Utils.createSlsb(MyStatelessBeanWithBindings.class);
                                
                                 // bind it to JNDI
                                 Ejb3RegistrarLocator.locateRegistrar().bind(sessionContainer.getName(), sessionContainer);
                                
                                 List<RemoteBindingMetaData> remoteBindingsMetadata = sessionContainer.getMetaData().getRemoteBindings();
                                
                                 assertNotNull("No RemoteBindingMetadata available", remoteBindingsMetadata);
                                 // make sure that the remotebinding metadata list has 1 @RemoteBinding information
                                 assertEquals("RemoteBindingMetadata does not have any RemoteBinding information available", remoteBindingsMetadata.size(), 1);
                                
                                 // Ensure that the RemoteBindingMetaData is created properly with the specified jndiBinding name.
                                 Iterator<RemoteBindingMetaData> remoteBindingsMetadataIterator = remoteBindingsMetadata.iterator();
                                 RemoteBindingMetaData remoteBindingMetadata = remoteBindingsMetadataIterator.next();
                                
                                 assertEquals("RemoteBinding JNDI name does not match " + MyStatelessBeanWithBindings.REMOTE_JNDI_NAME, MyStatelessBeanWithBindings.REMOTE_JNDI_NAME, remoteBindingMetadata
                                 .getJndiName());
                                
                                 // Now ensure that the RemoteBindingMetaData is used for binding the
                                 // remote interface of the bean.
                                 Context ctx = new InitialContext();
                                 String rJndiName = remoteBindingMetadata.getJndiName();
                                
                                 Object remoteBean = ctx.lookup(rJndiName); // fails here with exception
                                
                                 assertNotNull("Remote bean returned from JNDI lookup is null", remoteBean);
                                 assertTrue("Remote bean returned from JNDI lookup is NOT an instance of " + MyStatelessRemote.class, (remoteBean instanceof MyStatelessRemote));
                                
                                 }


                                Looks like there's some change related to EJBTHREE-1345 as part of which now atleast one interceptor is mandatory for remote beans?

                                Let me know, if you want me to update the JIRA (EJBTHREE-1423) with this updated test case. Actually, there hasn't been much changes in these test cases.

                                A couple of related questions:

                                1) What exactly are these client interceptors that is being checked for?
                                2) Why do we mandate these interceptors only for remote proxy and not for local proxy?


                                • 14. Re: EJBTHREE-1423 Test case for @RemoteBinding
                                  Andrew Rubinger Master

                                   

                                  "jaikiran" wrote:
                                  I tested this with jboss-metadata 1.0.0.Beta36.


                                  I just checked current HEAD of SVN; Proxy is still on Beta35:

                                  $ mvn dependency:tree -Dincludes=org.jboss.metadata |grep metadata
                                  [INFO] \- org.jboss.metadata:jboss-metadata:jar:1.0.0.Beta35:compile


                                  So I've just bumped the parent to the latest EJB3 Build SNAPSHOT, which will bring in Beta36.

                                  "jaikiran" wrote:
                                  My test cases which work on Remote beans are failing. The ones working with Local beans pass. Here's the exception, i see for all my remote bean test cases:
                                  Caused by: java.lang.AssertionError: Could not find Advice Stack with name: StatelessSessionClientInterceptors
                                   at org.jboss.ejb3.proxy.factory.ProxyFactoryBase.getInterceptors(ProxyFactoryBase.java:185)
                                   at


                                  Looks like there's some change related to EJBTHREE-1345 as part of which now atleast one interceptor is mandatory for remote beans?


                                  The error you're seeing is because the interceptors themselves are declared in a configured interceptor stack, which is required. @see ejb3-interceptors-aop.xml (either in EJB3 Core src/main/resources or EJB3 Proxy src/test/resources). Problem is that you need for your test to load up these definitions; this is what I'd meant by "Add to setupBeforeClass the boilerplate for deploying *-aop.xml, example in JndiSessionRegistrarTestCaseBase (else tests will fail)". :)

                                  "jaikiran" wrote:
                                  1) What exactly are these client interceptors that is being checked for?


                                  Stack, stack. :) In the case of the EJB3 Proxy Unit Tests, just the InvokeRemoteInterceptor. In EJB3 Core, they handle Client>Server Tx Propagation, bypassing the network stack on a @Remote invocation that takes place locally, propagation of security contexts, etc.

                                  "jaikiran" wrote:
                                  2) Why do we mandate these interceptors only for remote proxy and not for local proxy?


                                  Locally we just don't *need* to do that much; all is executed within the same JVM and Thread; see ProxyInvocationHandlerbase.getContainerLocally().

                                  S,
                                  ALR


                                  1 2 Previous Next