-
1. Re: EJBTHREE-1423 Test case for @RemoteBinding
alrubinger Jul 9, 2008 11:25 AM (in response to alrubinger)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 -
2. Re: EJBTHREE-1423 Test case for @RemoteBinding
jaikiran Jul 9, 2008 11:55 AM (in response to alrubinger)Thanks!
-
3. Re: EJBTHREE-1423 Test case for @RemoteBinding
jaikiran Jul 10, 2008 7:23 AM (in response to alrubinger)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 Jul 10, 2008 8:43 AM (in response to alrubinger)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
alrubinger Jul 27, 2008 6:14 AM (in response to alrubinger)Are you still seeing issues here, using jboss-metadata 1.0.0.Beta32?
S,
ALR -
6. Re: EJBTHREE-1423 Test case for @RemoteBinding
jaikiran Jul 28, 2008 1:10 AM (in response to alrubinger)I will run that test case with Beta32 and let you know.
-
7. Re: EJBTHREE-1423 Test case for @RemoteBinding
jaikiran Jul 28, 2008 4:58 AM (in response to alrubinger)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
alrubinger Aug 9, 2008 3:14 PM (in response to alrubinger)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
emuckenhuber Aug 9, 2008 8:21 PM (in response to alrubinger)"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
alrubinger Aug 9, 2008 8:29 PM (in response to alrubinger)"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 Aug 11, 2008 11:20 AM (in response to alrubinger)"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
alrubinger Aug 14, 2008 3:10 AM (in response to alrubinger)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 Aug 18, 2008 6:30 AM (in response to alrubinger)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
alrubinger Aug 18, 2008 10:25 AM (in response to alrubinger)"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