Using @EJB annotation instead of looking up for EJB

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Using @EJB annotation instead of looking up for EJB

nemesis_sun
Hi guys,

I'm new and on the way of learning Geronimo. I have this simple application, there is one EJB application and one App Client. In the EJB app, I have one remote interface (with "@Remote"), one EJB(with "@Stateless"). In the App Client, I have a Main class which accesses the EJB and calls some of its functions.

The problem is, I am able to use InitialContext.lookup() to retrieve an instance of the EJB, but not so with the @EJB annotation. It returns a NULL value.

So can someone help me on this issue, how to use @EJB instead of lookup()?
Please also note that all the annotations I just listed are without any element. I know with this alone the server may not have enough info on where to look for the EJB, so maybe there is some way to specify it, either in those annotations or the the deployment plan (my priority is in the annotations, if there is any)
Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

Forrest Xia
Refer to bank sample, for example,
https://svn.apache.org/repos/asf/geronimo/samples/tags/samples-parent-2.2.1/samples/bank/

On Mon, Jun 25, 2012 at 12:55 PM, nemesis_sun <[hidden email]> wrote:
Hi guys,

I'm new and on the way of learning Geronimo. I have this simple application,
there is one EJB application and one App Client. In the EJB app, I have one
remote interface (with "@Remote"), one EJB(with "@Stateless"). In the App
Client, I have a Main class which accesses the EJB and calls some of its
functions.

The problem is, I am able to use InitialContext.lookup() to retrieve an
instance of the EJB, but not so with the @EJB annotation. It returns a NULL
value.

So can someone help me on this issue, how to use @EJB instead of lookup()?
Please also note that all the annotations I just listed are without any
element. I know with this alone the server may not have enough info on where
to look for the EJB, so maybe there is some way to specify it, either in
those annotations or the the deployment plan (my priority is in the
annotations, if there is any)

--
View this message in context: http://apache-geronimo.328035.n3.nabble.com/Using-EJB-annotation-instead-of-looking-up-for-EJB-tp3985253.html
Sent from the Users mailing list archive at Nabble.com.



--
Thanks!

Regards, Forrest

Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

nemesis_sun
Hi Forrest,

I couldn't find an example in the given link on how to use @EJB instead of InitialContext.lookup()
The client there still uses lookup() to get EJB.
Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

nemesis_sun
I have done some research and found a geronimo tutorial here discussing about injecting an instance of EJB into a servlet, and using @EJB with a "name" element.
In addition to that, geronimo-web.xml also has to be edited by adding a <dependency> and a <ejb-ref> element.
I have done this similarly to the geronimo-application-client.xml in the App Client module and tried running it, but nothing happened, still the same null object was returned.

One more thing is that I didn't add the App Client module to the server, as there was some stupid error during deployment and I was able to run it using "Run as Java Application". I don't know if there is any difference, if there is then I will have to resolve that error too.

Please help.
Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

David Jencks

On Jun 25, 2012, at 11:41 AM, nemesis_sun wrote:

> I have done some research and found a geronimo tutorial here discussing about
> injecting an instance of EJB into a servlet, and using @EJB with a "name"
> element.
> In addition to that, geronimo-web.xml also has to be edited by adding a
> <dependency> and a <ejb-ref> element.
> I have done this similarly to the geronimo-application-client.xml in the App
> Client module and tried running it, but nothing happened, still the same
> null object was returned.
>
> One more thing is that I didn't add the App Client module to the server, as
> there was some stupid error during deployment and I was able to run it using
> "Run as Java Application". I don't know if there is any difference, if there
> is then I will have to resolve that error too.

I'm not sure what you mean by that, I don't use eclipse and run everything from the command line.  You need to include the app client in an ear with the ejb (or web including ejbs) module and deploy it as a unit, and you need to start the app client using geronimo.  I'm not sure where the instructions are for this any more, basically aside from demos no one has ever used an app client, hopefully the bank sample Forrest pointed at has some instructions.

I really doubt there is an easy way to run an app client through eclipse.  It would look like starting some kind of server configuration if there is a way.

An app client uses large parts of the geronimo server and even if you package it up like a Main-based application it won't work at all without running i through the geronimo app client container.

thanks
david jencks

>
> Please help.
>
> --
> View this message in context: http://apache-geronimo.328035.n3.nabble.com/Using-EJB-annotation-instead-of-looking-up-for-EJB-tp3985253p3985261.html
> Sent from the Users mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

nemesis_sun
Thanks for replying, David

Basically what I want to do is to learn how Application Client and EJB communicate with each other (and Web after that), and how to package them into an EAR (so when I run the EAR, the App Client will run and call EJB functions). So yes, this is just a demo.

I coded an App Client and an EJB. The App Client should be able to talk with the EJB. I have created 2 projects in Eclipse, one is HRManager-Client (via Application Client project wizard), one is HRManager-EJB (via EJB project wizard). I can deploy and publish the EJB module into the Geronimo server. However, I am not able to do so with the Client as there is an error (in two cases, as a separate module and as a module inside an EAR together with the EJB). Therefore, I found a way to run it by "Run as Java Application" in Eclipse. In this case, the Client can retrieve the EJB by setting up the InitialContext and call lookup(), but not so with @EJB.

What I am confused right now is:

1. Does running the Client by right-click->run as java app put the client into the app client server, because for @EJB injection to succeed, the client must be managed by a client server. If it does not, then there is no way to use @EJB in this case.

2. Please help me with the error when deploying the Client module into Geronimo. After that, I can try creating an EAR on the server and run the whole thing, in that case there is the possibility the @EJB will take effect, as the Client will be deployed in the server.

3. I really doubt about the validity of the .xml files in my project, can you please take a look at it. Do I have to add something so that @EJB can work?

I attach to source code of the 2 projects here for reference. Thank you for your help.sample.zip

Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

nemesis_sun
This is the error I encountered when Add the App Client to Geronimo

Distribution of module failed.  See log for details.
AppClientModuleBuilder: Could not load main class: Main
org.apache.geronimo.common.DeploymentException: AppClientModuleBuilder: Could not load main class: Main
        at org.apache.geronimo.client.builder.AppClientModuleBuilder.createAppClientClassFinder(AppClientModuleBuilder.java:807)
        at org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans(AppClientModuleBuilder.java:689)
        at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:652)
        at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
        at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:136)
        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.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
        at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
        at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
        at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
        at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342)
        at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
        at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
        at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
        at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
        at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
        at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
        at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
        at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1367)
        at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
        at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
        at sun.rmi.transport.Transport$1.run(Transport.java:159)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: Main in classloader HRManager/Client/1.0/car
        at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:407)
        at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:257)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
        at org.apache.geronimo.client.builder.AppClientModuleBuilder.createAppClientClassFinder(AppClientModuleBuilder.java:804)
        ... 42 more
Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

Ivan Xu
I have replied in another thread, and the sample seems to prove my guess, the full class name is client.Main, while in the MANIFEST.MF, it writes Main-Class: Main.

2012/6/26 nemesis_sun <[hidden email]>
This is the error I encountered when Add the App Client to Geronimo

Distribution of module failed.  See log for details.
AppClientModuleBuilder: Could not load main class: Main
org.apache.geronimo.common.DeploymentException: AppClientModuleBuilder:
Could not load main class: Main
       at
org.apache.geronimo.client.builder.AppClientModuleBuilder.createAppClientClassFinder(AppClientModuleBuilder.java:807)
       at
org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans(AppClientModuleBuilder.java:689)
       at
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:652)
       at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
       at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:136)
       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.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
       at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
       at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
       at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
       at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342)
       at sun.reflect.GeneratedMethodAccessor138.invoke(Unknown Source)
       at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:597)
       at
org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
       at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
       at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
       at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
       at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172)
       at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
       at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
       at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
       at
javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
       at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
       at java.security.AccessController.doPrivileged(Native Method)
       at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1367)
       at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
       at sun.reflect.GeneratedMethodAccessor123.invoke(Unknown Source)
       at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:597)
       at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
       at sun.rmi.transport.Transport$1.run(Transport.java:159)
       at java.security.AccessController.doPrivileged(Native Method)
       at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
       at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
       at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
       at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
       at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
       at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
       at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.ClassNotFoundException: Main in classloader
HRManager/Client/1.0/car
       at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadOptimizedClass(MultiParentClassLoader.java:407)
       at
org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(MultiParentClassLoader.java:257)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
       at
org.apache.geronimo.client.builder.AppClientModuleBuilder.createAppClientClassFinder(AppClientModuleBuilder.java:804)
       ... 42 more

--
View this message in context: http://apache-geronimo.328035.n3.nabble.com/Using-EJB-annotation-instead-of-looking-up-for-EJB-tp3985253p3985268.html
Sent from the Users mailing list archive at Nabble.com.



--
Ivan
Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

nemesis_sun
Hi Ivan,

I changed Main to client.Main and there is a different error. This time it looks like the server found the class, but could not fully load it, I suspect it's related to EJB.

-------------------------------------------------------------------------
 
Distribution of module failed.  See log for details.
Could not fully load class: client.Main
 due to:Lejb/HRManager;
 in classLoader:
[org.apache.geronimo.kernel.classloader.JarFileClassLoader id=HRManager/Client/1.0/car]
java.lang.NoClassDefFoundError: Could not fully load class: client.Main
 due to:Lejb/HRManager;
 in classLoader:
[org.apache.geronimo.kernel.classloader.JarFileClassLoader id=HRManager/Client/1.0/car]
        at org.apache.xbean.finder.ClassFinder.<init>(ClassFinder.java:161)
        at org.apache.geronimo.client.builder.AppClientModuleBuilder.createAppClientClassFinder(AppClientModuleBuilder.java:827)
        at org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans(AppClientModuleBuilder.java:689)
        at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:652)
        at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
        at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:136)
        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.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
        at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
        at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
        at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
        at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:342)
        at sun.reflect.GeneratedMethodAccessor139.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
        at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
        at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:851)
        at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
        at org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:172)
        at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
        at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
        at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427)
        at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72)
        at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1367)
        at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788)
        at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
        at sun.rmi.transport.Transport$1.run(Transport.java:159)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

Forrest Xia
In reply to this post by nemesis_sun


On Mon, Jun 25, 2012 at 1:34 PM, nemesis_sun <[hidden email]> wrote:
Hi Forrest,

I couldn't find an example in the given link on how to use @EJB instead of
InitialContext.lookup()
The client there still uses lookup() to get EJB.
Just made some updates to bank sample in the 3.0 branch -> https://svn.apache.org/repos/asf/geronimo/samples/branches/3.0/samples/javaee5/bank/

You can compile it and run against 3.0.0-SNAPSHOT build, for app client run, just execute a command like this:
$GEORNIMO_HOME/bin/client org.apache.geronimo.samples.javaee5/bank-tomcat_bank-client-3.0.0-SNAPSHOT.jar/3.0.0-SNAPSHOT/car

--
View this message in context: http://apache-geronimo.328035.n3.nabble.com/Using-EJB-annotation-instead-of-looking-up-for-EJB-tp3985253p3985255.html
Sent from the Users mailing list archive at Nabble.com.



--
Thanks!

Regards, Forrest

Reply | Threaded
Open this post in threaded view
|

Re: Using @EJB annotation instead of looking up for EJB

Ivan Xu
Hi, just have a close look at your sample application, with the changes below, I could invoke the application client and the @EJB also works.

a. Add Class-Path: HRManager-EJB.jar in the MANIFEST.MF file in the client application

From the spec side, client application may have access to other components in the same EAR application, that is not must. The changes above is just to make sure that it could see the classes from the EJB application. Another possible solution is to add those ejb client API in the client application file.

b. Update the client deployment plan with below, the server-environment does NOT mean the dependency configuration, think you could find more description for that in the wiki.

--->
<dep:server-environment>
<dep:moduleId>
<dep:groupId>HRManager</dep:groupId>
<dep:artifactId>client-server</dep:artifactId>
<dep:version>1.0</dep:version>
<dep:type>car</dep:type>
</dep:moduleId>
</dep:server-environment>

2012/6/26 Forrest Xia <[hidden email]>


On Mon, Jun 25, 2012 at 1:34 PM, nemesis_sun <[hidden email]> wrote:
Hi Forrest,

I couldn't find an example in the given link on how to use @EJB instead of
InitialContext.lookup()
The client there still uses lookup() to get EJB.
Just made some updates to bank sample in the 3.0 branch -> https://svn.apache.org/repos/asf/geronimo/samples/branches/3.0/samples/javaee5/bank/

You can compile it and run against 3.0.0-SNAPSHOT build, for app client run, just execute a command like this:
$GEORNIMO_HOME/bin/client org.apache.geronimo.samples.javaee5/bank-tomcat_bank-client-3.0.0-SNAPSHOT.jar/3.0.0-SNAPSHOT/car

--
View this message in context: http://apache-geronimo.328035.n3.nabble.com/Using-EJB-annotation-instead-of-looking-up-for-EJB-tp3985253p3985255.html
Sent from the Users mailing list archive at Nabble.com.



--
Thanks!

Regards, Forrest




--
Ivan