-
1. Re: Local JNDI Lookup only via global namespace possible in Wildfly 10 ??
jaysensharma Dec 10, 2015 8:38 AM (in response to fambad)You are doing a typo mistake in your lookup JNDI name:
The output JNDI name is as following:
java:app/JBoss10-Test_EJB_1/StatelessBean!marabu.test.wildfly.StatelessLocal
But your code is looking up java:app/JBoss10-Test_EJB_1!StatelessBean!marabu.test.wildfly.StatelessLocal
So please change the code as:
OLD
StatelessLocal l = InitialContext.doLookup( "java:app/JBoss10-Test_EJB_1!StatelessBean!marabu.test.wildfly.StatelessLocal" );
NEW
StatelessLocal l = InitialContext.doLookup( "java:app/JBoss10-Test_EJB_1/StatelessBean!marabu.test.wildfly.StatelessLocal" );
Notice there is an ! mark between "JBoss10-Test_EJB_1!StatelessBean" (incorrect)
it should be "JBoss10-Test_EJB_1/StatelessBean" (correct)
Any of the following JNDI name/code should be working:
StatelessLocal l = InitialContext.doLookup( "java:app/JBoss10-Test_EJB_1/StatelessBean!marabu.test.wildfly.StatelessLocal" ); OR StatelessLocal l = InitialContext.doLookup( "java:app/JBoss10-Test_EJB_1/StatelessBean" );
-
2. Re: Local JNDI Lookup only via global namespace possible in Wildfly 10 ??
jaysensharma Dec 10, 2015 8:40 AM (in response to fambad)Above comment talks about "java:app" issue. Now about the "java:module".
The "java:module" namespace is used to look up local enterprise beans within the same module.
-
3. Re: Local JNDI Lookup only via global namespace possible in Wildfly 10 ??
fambad Dec 10, 2015 10:46 AM (in response to jaysensharma)it was a typo mistake only in my forum post. I tried again this is the error message: javax.naming.NameNotFoundException: java:app/JBoss10-Test_EJB_1/StatelessBean!marabu.test.wildfly.StatelessLocal.
A also tried the lookup within the same module using app and module namespace. And it didn't work. Only the global lookup works.
Here the error message for the module lookup when calling lookup within the same module of the Statelessbean class: javax.naming.NameNotFoundException: java:module/StatelessBean!marabu.test.wildfly.StatelessLocal
And I have another question:
In the oracle sun documentation the lookup string is documented as follows:
java:global[/application name]/module name/enterprise bean name[/interface name] --> here the interface name is separated by "/" not by "!". What is the difference between "/" and "!". Lookup with "/" as separator for the interface name did not work.
-
4. Re: Local JNDI Lookup only via global namespace possible in Wildfly 10 ??
jaysensharma Dec 10, 2015 11:24 AM (in response to fambad)There is some thing wrong with your test case (apart from the type mistake which i mentioned earlier) please attach the complete test case here.
Or else try the TestCase which i developed at my end to verify if the Local EJB lookup is working fine in WildFLy10 or not.
My EJB Code is as following:
//CalculatorBean.java package calculator; import javax.ejb.*; import javax.naming.*; import java.util.*; @Stateless(name = "CallerName", mappedName = "CallerMappedName") public class CallerBean implements CallerRemote { CalculatorLocal calculatorLocal; public String testMethod() { System.out.println("\n\n\t Bean testMethod() called...."); return "DONE----returned"; } public String callEJBOne(int a, int b) { int result=0; try{ String jndiName="java:app/EJB-One/CalculatorBean!calculator.CalculatorLocal"; // NOTICE calculatorLocal = (CalculatorLocal) InitialContext.doLookup(jndiName); System.out.println("\n\n\t Bean callEJBOne(a,b) called...."); result=calculatorLocal.add(a,b); System.out.println("\n\n\t [CallerBean] Got the Resule from CalculatorBean ---Sum = "+result); } catch(Exception e){ e.printStackTrace(); } return "DONE----result = "+result; } }
Attached TestCase
===============
1. Deploy the attached "EJBs_App.ear" on WildFly10
2. Open a terminal and Set the classpath to include the "wildfly-10.0.0.CR3-SNAPSHOT/bin/client/jboss-client.jar"
3. Run the client as following:
java TestClientEjb3
Server Output
==============
21:37:43,769 INFO [org.jboss.weld.deployer] (MSC service thread 1-7) WFLYWELD0003: Processing weld deployment EJB-Two.jar 21:37:43,769 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0003: Processing weld deployment EJB-One.jar 21:37:43,782 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-5) WFLYEJB0473: JNDI bindings for session bean named 'CalculatorBean' in deployment unit 'subdeployment "EJB-One.jar" of deployment "EJBs_App.ear"' are as follows: java:global/EJBs_App/EJB-One/CalculatorBean!calculator.CalculatorLocal java:app/EJB-One/CalculatorBean!calculator.CalculatorLocal java:module/CalculatorBean!calculator.CalculatorLocal java:global/EJBs_App/EJB-One/CalculatorBean java:app/EJB-One/CalculatorBean java:module/CalculatorBean 21:37:43,783 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-7) WFLYEJB0473: JNDI bindings for session bean named 'CallerName' in deployment unit 'subdeployment "EJB-Two.jar" of deployment "EJBs_App.ear"' are as follows: java:global/EJBs_App/EJB-Two/CallerName!calculator.CallerRemote java:app/EJB-Two/CallerName!calculator.CallerRemote java:module/CallerName!calculator.CallerRemote java:jboss/exported/EJBs_App/EJB-Two/CallerName!calculator.CallerRemote java:global/EJBs_App/EJB-Two/CallerName java:app/EJB-Two/CallerName java:module/CallerName 21:37:43,795 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0006: Starting Services for CDI deployment: EJBs_App.ear 21:37:43,825 INFO [org.jboss.weld.Version] (MSC service thread 1-2) WELD-000900: 2.3.0 (Final) 21:37:43,839 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) WFLYWELD0009: Starting weld service for deployment EJBs_App.ear 21:37:44,476 INFO [org.jboss.as.server] (ServerService Thread Pool -- 34) WFLYSRV0010: Deployed "EJBs_App.ear" (runtime-name : "EJBs_App.ear") 21:37:44,526 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management 21:37:44,526 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990 21:37:44,526 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR5) started in 3461ms - Started 400 of 684 services (339 services are lazy, passive or on-demand) 21:37:52,845 INFO [org.jboss.ejb.client] (pool-1-thread-1) JBoss EJB Client version 2.1.2.Final 21:37:52,969 INFO [stdout] (EJB default - 1) 21:37:52,969 INFO [stdout] (EJB default - 1) 21:37:52,970 INFO [stdout] (EJB default - 1) Bean callEJBOne(a,b) called.... 21:37:52,970 INFO [stdout] (EJB default - 1) 21:37:52,970 INFO [stdout] (EJB default - 1) 21:37:52,970 INFO [stdout] (EJB default - 1) Addition is : 3000 21:37:52,971 INFO [stdout] (EJB default - 1) 21:37:52,971 INFO [stdout] (EJB default - 1) 21:37:52,971 INFO [stdout] (EJB default - 1) [CallerBean] Got the Resule from CalculatorBean ---Sum = 3000
Client Output:
==============
$ java TestClientEjb3 Hello ... Dec 10, 2015 9:37:00 PM org.xnio.Xnio <clinit> INFO: XNIO version 3.3.2.Final Dec 10, 2015 9:37:01 PM org.xnio.nio.NioXnio <clinit> INFO: XNIO NIO Implementation Version 3.3.2.Final Dec 10, 2015 9:37:01 PM org.jboss.remoting3.EndpointImpl <clinit> INFO: JBoss Remoting version 4.0.14.Final Got initial Context: javax.naming.InitialContext@7a450ea8 Dec 10, 2015 9:37:01 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage INFO: EJBCLIENT000017: Received server version 2 and marshalling strategies [river] Dec 10, 2015 9:37:01 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@6c3a6465, receiver=Remoting connection EJB receiver [connection=Remoting connection <505d7a8a>,channel=jboss.ejb,nodename=banl13bca644a-5]} on channel Channel ID d523d1ff (outbound) of Remoting connection 2f478e10 to localhost/127.0.0.1:8080 Dec 10, 2015 9:37:01 PM org.jboss.ejb.client.EJBClient <clinit> INFO: JBoss EJB Client version 2.1.2.Final Got CallerRemote : Proxy for remote EJB StatelessEJBLocator for "EJBs_App/EJB-Two/CallerName", view is interface calculator.CallerRemote, affinity is None ONE----result = DONE----result = 3000
-
5. Re: Local JNDI Lookup only via global namespace possible in Wildfly 10 ??
jaysensharma Dec 10, 2015 11:34 AM (in response to fambad)Regarding your query: ---> java:global[/application name]/module name/enterprise bean name[/interface name] --> here the interface name is separated by "/" not by "!". What is the difference between "/" and "!". Lookup with "/" as separator for the interface name did not work.
Please refer to the WildFly container documentation: https://docs.jboss.org/author/display/WFLY10/EJB+invocations+from+a+remote+client+using+JNDI
For stateless beans:
ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>
For stateful beans:
ejb:<app-name>/<module-name>/<distinct-name>/<bean-name>!<fully-qualified-classname-of-the-remote-interface>?stateful
-
6. Re: Local JNDI Lookup only via global namespace possible in Wildfly 10 ??
fambad Dec 11, 2015 2:47 AM (in response to jaysensharma)Hi,
thanks for the sample. I could deploy it and it works.
And now I have found the reason for the problem.
I am using a singleton bean that I registered at the wildfly mbean server as management bean to test my lookup using a management method.
When I register the "THIS" Instance at the MBean Server then the later lookup using the jndi app binding fails. When I register the proxy of the singleton bean at the mbean server the lookup using over the app binding works fine.
I have changed your calculator sample and added 2 MBeans:
- test.calculator:service=FailCaller --> uses MBean registration with the "THIS" instance and fails when lookup for the app binding of the calculator
- test.calculator:service=SuccessCaller --> uses MBean registration with the proxy instance and succeed when lookup for the app binding of the calculator
So now I could change my code for the mbean registration using the singleton proxy but then I run into another problem. Because in my real application I implement the javax.management.MBeanRegistration interface to simulate the old jboss @Service lifecycle methods (create, start stop, destroy). (We want to migrate from JBoss 6.0 to Wildfly 10 and want to minimize the code changes).
But when I register the mbean in the @postconstruct method of the singleton bean the implicit call of the lifecycle methods of the javax.management.MBeanRegistration interface by the mbean server will result in a new call to the singletons @PostConstrcut method and this is not allowed, prevented by the server, and results in an error.
That's why I can't use the proxy. So is there any internal differnce either using the app lookup or global lookup? Maybe Performance issues or anything else?
One Note to my other question using "!" instead of "/" to separate the interface name:
I know the documentation of wildfly you have posted and I coded my samples as it was described there. But I only want to understand why wildfly using another lookup string as described in the suns javaee6 documentation: http://docs.oracle.com/javaee/6/tutorial/doc/gipjf.html#girgn