6.
Testing our Bean
Now that our bean is written, we need to deploy, run and test it.
The deploying and running step is done by using MyEclipse to
deploy the bean to a Java EE 5.0 compliant application server,
for this tutorial we are using
Glassfish 2. After our bean is deployed, we will
write a simple Java class that will load our EJB3 using JNDI, and
call it's
doSomething() method.
Deploying the Bean
First, assuming you have
Glassfish 2 setup, you can quickly deploy the
project by using the MyEclipse Deployment Tool:
Then make sure the project is selected, and click
Add to add a new deployment for the project to
Glassfish 2:
On the new deployment dialog, make sure to select the app server
you want to deploy the bean to (must be Java EE 5.0 compliant for
the purposes of this tutorial) and hit Finish:
Confirm that the deployment was successful and hit OK:
Now that our EJB is deployed, we can start the application server
up before writing our simple test case. First click the
Application Server launch drop down to select the app server to
start:
Then the application server will start up, and likely print
messages to the console about successfully deploying the Session
Bean:
At this point, we are ready to write our test class that will
call the EJB.
Testing the Bean
To start, we need to create a new Java class in our package to
test our bean with:
Then name the test class and tell MyEclipse to generate a
main method for it:
Before we are ready to add code to our client and run it, we need
to
add appserv-rt.jar to our Build Path. This JAR
is from the
Glassfish 2 library directory and contains a
customized
jndi.properties file that will allow us to connect
directly to the
Glassfish 2 JNDI context automatically and
retrieve our bean with almost no effort. So let's add that JAR
now:
Then switch to the
Libraries tab, and click
Add External JAR to find the JAR and add it:
Drill down into the
Glassfish 2 install directory, then into the
/lib directory and select the
appserver-rt.jar file and add it:
After it's added, hit
OK:
Now we are ready to add code to our test client and run it. The
actual code, thanks to the JAR we just added, is surprisingly
simple:
public static void main(String[] args) {
try {
InitialContext ctx = new
InitialContext();
MyBeanRemote bean = (
MyBeanRemote) ctx.lookup("
com.myeclipseide.ejb3.MyBeanRemote");
bean.doSomething();
} catch (NamingException e) {
e.printStackTrace();
}
}
|
|
Session Bean Test Client Code
|
There are two key things to notice in the code above to make
sense of it:
-
We cast the returned bean not to
MyBean but to the interface
MyRemoteBean because we are requesting the remote bean
from the JNDI context. As mentioned above, the methods exposed
by the different Local/Remote interfaces could vary, so we need
to stick to the interface we are requesting.
-
Glassfish uses a default JNDI name-binding for EJBs that don't
specify one. If you scroll back up to the server-log screenshot,
you'll notice that the default name is printed out in the log.
This default name is different from application to application
server, and most folks would use
mappedName value of the
@Stateless annotation to specify a new binding across
all app servers. For example:
@Stateless(name="MyBean",
mappedName="ejb/MyBean")
-
Once we have the bean, we can treat it like a local instance,
and simply invoke it.
Because of how we wrote the code for our bean (
System.out.println) the result of #3 is output to the
application server console in MyEclipse:
Our test client worked!
|
