This chapter looks at one of the principal types of component in the Java 2 Platform, Enterprise Edition (J2EE) — Enterprise JavaBeans (EJBs). See how EJBs are applied and how they are deployed. (This is chapter 4 from Sams Publishers, author Martin Bond, et. al., Teach Yourself J2EE in 21 Days, second edition, ISBN: 0-672-32558-6).
If you have encountered difficulties running the case study application, the following may help you in resolving your problems:
Have you started the J2EE RI?
If you are not sure, try locating its console window or looking for it in the list of processes or applications on your machine. Try browsing to http://localhost:4848to view the Admin Console.
At J2EE RI install time did you define the HTTP server port to be a different value to 8000?
Try browsing to http://localhost:8000 to verify you are using port 8000. If you selected a different HTTP server port number you will have to use your value rather than 8000 as shown in all the examples in this book.
Have you started the PointBase database?
Try running the initial database test at the end of Day 2 exercise to ensure that the data is present and that the database server is running.
Have you verified the EJBs?
Use the asant build files to run the command line verifier. Run either
as discussed in the section "Case Study asant Build Files."
Have you deployed the EJBs?
By opening the EAR file, you are simply loading the enterprise application into the deploytool environment. You must explicitly deploy the application to the server you are using through the Tools, Deploy menu. Check that you application has been deployed using the Admin Console application at http://localhost:4848/asadmin.
Have you retrieved the client JAR file after deploying your application?
Retrieve your application client using
Does the J2EE RI console window show any exceptions or errors?
Does the J2EE server.log file under the /domains/domain1/logs directory in J2EE_HOME show errors?
If you still have problems and you suspect there is a problem with the configuration of your J2EE RI, you can re-install, or you could try manually removing the deployed applications. You will find manually removing the applications easier than re-installing.
To manually remove an EJB component, you must perform the following steps, which are described in detail following this list:
Stop the J2EE RI server.
Remove the application from the J2EE domains/domain1/applications/j2ee-apps directory.
Remove the application from the J2EE server configuration (domains/domain1/config/domain.xml) file.
Restart the J2EE server.
You can stop the J2EE server using the command
or simply close down the J2EE RI window.
Once the J2EE RI has stopped you will be able to edit the configuration to manually remove an offending application.
In the J2EE home directory there is a domains sub-directory, inside which is a domain1 directory. Find the applications/j2ee-apps directory, and beneath this a subdirectory for each deployed application. Delete the offending application directory. Make sure you do not delete the supplied MejbApp and __ejb_container_timer_app directories, otherwise you will need to reinstall the J2EE RI.
In the domains/domain1 directory in the J2EE_HOME directory there is a config directory and a file called domain.xml. For safety, take a backup copy of this file before changing it. Now edit the domain.xml file and find the <applications> tag element (near the start of the file). Look for a nested <j2ee-application> with a name attribute matching your application, the entry for the example agency application will look like
Delete the <j2ee-application> element for your application. Make sure you do not delete the <applications> element itself or corrupt any other part of this file.
Restart the J2EE server and (hopefully) everything will still work and you can try deploying your application again. If you still have problems, your only option is to remove the J2EE SDK, reinstall and start again.
Today, you have seen common ways that EJBs are used in applications and why you would want to use them. You have seen that an EJB will have a home interface, a business or remote interface, and an implementation. You have seen how the EJB container will provide much of the underlying code to support the EJB, and that it relies on detailed deployment information that defines the EJB's requirements.
You have also seen that a J2EE application consists of components and deployment information and how the server-side part of such an application can be deployed. You have seen a client that is able to use such server-side components and the code required to write such a client.
How many Java classes and interfaces must you write to create an EJB?
The EJB writer must define a remote (or business) interface, a home interface, and the bean implementation itself.
Why does an EJB run inside a container?
The container provides many services to the EJB, including distribution, lifecycle, naming/registration, transaction management, security/authentication, and persistence. If the container did not exist, you would have to write all the code to interact with these services yourself.
What issues are there in passing an object as part of a remote method call?
To be passed as an argument or return type, an object must be either serializable or remote. If it is neither of these, an error will occur at runtime. If an object is defined as serializable, a new copy will be created and passed/returned. This can add to the overhead of making the method call, but it is a very useful tool when trying to cut down the amount of network traffic between clients and EJBs (as you will see later on Day 18).
Most of the deployment descriptor information is straightforward, but what is the difference between a <resource-ref> and an <env-entry>, and what sort of information is contained in each type of entry?
<resource-ref> is part of a deployment descriptor that defines an external resource used by a J2EE component. The <resource-ref> will define a name and type for a resource together with other information for the container. To access a resource defined in a <resource-ref>, you would use JNDI to look up its name (for example java:comp/env/jdbc/Agency).
An <env-entry>, on the other hand, contains information that is intended only for the EJB itself. It will define a name, a class type and a value. The contents of <env-entry> elements are usually strings. Again, you would use JNDI to look up its name (for example java:comp/env/AgencyName).
The intention of this day is for you to familiarize yourself with the EJB environment and the use of EJBs. To ensure that you are comfortable with these areas, you should attempt the following tasks.
If you have not already done so, follow the steps to deploy the example Agency EJB from the Day04/exercise directory on the Web site using deploytool.
Examine the information displayed by deploytool and make sure that you can identify where the resource reference for the Agency JDBC connection is set, where the environment reference for the agency name is set, and where the JNDI name of the Agency EJB itself is set.
From within the Day04/exercise directory run the command "asant verify-j2ee-ri" to verify your application.
Use the appclient command shown in today's lesson and run the SimpleClient example. Make sure that this client runs without errors and successfully lists all the customers in the agency database.
Try changing the name under which the EJB is registered in JNDI using deploytool. Change the JNDI name used by your client to find the Agency EJB and make sure that it still works.
Use the asant build files instead of deploytool to compile, build, verify and deploy the example Agency application.
Edit the dd/agency/sun-j2ee-ri.xml file (make a backup first of course) and change the JNDI name for the Agency Session EJB. Change the JNDI name used by your client to find the Agency EJB and make sure that it still works.
This chapter is from Teach Yourself J2EE in 21 Days, second edition, by Martin Bond et. al. (Sams, 2004, ISBN: 0-672-32558-6). Check it out at your favorite bookstore today. Buy this book now.