All Examples  All EJB Examples

Building Enterprise JavaBean examples

This document describes how to build the Enterprise JavaBeans examples.

We've done a few things in creating the examples that are different than what you'd do in a production environment where you have written your own beans. We did these to make the examples easier to understand and simpler to build.

We've supplied shell scripts to build the examples. In a production environment, you probably wouldn't use shell scripts, but would use a makefile such as GNUMake.

Package structure

Each of our examples has one or more client applications ("Client", "MultiClient") and sometimes a servlet ("Servlet"), so we've placed these classes into the same package as the EJBean. Classes in each example that are intended to only be on the client have the word "Client" in the classname. The servlet (if there's one) is always called "Servlet". All classes that are intended to only be on the server have the word "Bean" in the classname. The scripts use this naming system to move the classes once they are compiled to the correct directory.

In a production environment, you normally wouldn't have any client code in the same package as your EJBean, and your scripts could be much simpler.

How to use the scripts

There's scripts for building the EJB examples in a high-level directory for each group of examples. We have provided scripts for UNIX (build.sh) and Windows NT (build.cmd): The Windows NT scripts for /examples/cluster/ejb, /examples/ejb/, /examples/jolt/ejb/ all take an option "-ms" that will build the EJBeans using Microsoft's JDK for Java.

The script in /examples/ejb takes two arguments that determine which of the examples found in /examples/ejb are built, such as shown in this entry for Windows: 

$ build basic beanManaged
With the above exceptions, the scripts don't take any arguments.

The scripts build an example and place the files in the correct locations. Each script generates a .jar file containing the EJBean(s) required for the example.

Note:

Using the scripts with Microsoft SDK for Java

Use -ms if you're running the WebLogic Server with Microsoft SDK for Java; it runs the ejbc compiler with Jview to solve a problem with serialization with Jview.

The scripts call the jar command. Microsofts SDK for Java does not have a jar command, so you must download the Java SDK from Sun, install it, and add the SDK's bin directory to the end of your PATH to provide access to the jar tool while you are building the examples.

The Sun jar utility depends upon Java classes that are not included in Microsoft SDK for Java, so you must also add the Sun SDK's classes.zip file to the end of the classpath in your development shell. The classes.zip file is found in the lib subdirectory of the Sun SDK installation.

Note: In order to deploy the bean in a server running under Microsoft SDK for Java, you must also add the EJBean .jar file to the CLASSPATH of your WebLogic Server. For more information on how to properly set CLASSPATH when starting the server, see Setting the classpath.

How the scripts work

At first glance, the scripts probably look pretty complicated. That's because we've added error-handling and dependency checking for the different cases involved. But at their heart, the scripts do a series of simple steps. Let's look at the /examples/ejb/build.bat, and look at its eight steps. In the code fragments below, we've removed the error handling lines and the sections that deal with dependency checking:
  1. Create directories:
    We create a temp directory for working in, and check that the appropriate client and servlet classes directories exist in the myserver directory: 
      if not exist %TEMP%\nul mkdir %TEMP%
  if not exist %EJB_CLIENT_CLASSES%\nul mkdir %EJB_CLIENT_CLASSES%
  if not exist %SERVLET_CLASSES%\nul mkdir ..\%MYSERVERCLASSES%

  2. Compile Java classes:
    We then compile all the Java classes in the example: 
      %JAVAC% -d %TEMP% %DIRECTORY%\*.java

  3. Copy classes to the clientclasses and servletclasses directories:
    Next, we copy the Java classfiles to the appropriate directories. We copy Client and the EJB Bean interfaces to the /myserver/clientclasses directory, and the Servlet (if there's one) to the /myserver/servletclasses directory: 
      xcopy %EJB_TEMP% %EJB_CLIENT_CLASSES% /i
  xcopy %EJB_TEMP%\*Servlet.class %SERVLET_CLASSES% /i

  4. Delete the Client code from the temp directory and the Bean or Servlet code from client directory:
    Now, we cleanup the directories. We delete the Client and Servlet code from the temp directory, and we remove any Bean classes and Servlet code from the client directory. (The Client doesn't directly interact with the Bean classes, only the Home and Remote interfaces, and any exception classes, so there's no need for the Bean classe itself on the client.): 

      del /q %EJB_TEMP%\*Client*.class
  del /q %EJB_TEMP%\*Servlet.class
  del /q %EJB_CLIENT_CLASSES%\*Bean*.class
  del /q %EJB_CLIENT_CLASSES%\*Servlet.class

  5. Create a .ser file from the deployment descriptor:
    We use the deployment descriptor and the EJB utility DDCreator to create a serialized deployment descriptor. So that the different scripts can work with many different beans, we always call the serialized deployment descriptor DD.ser: 
      %JAVA% weblogic.ejb.utils.DDCreator -d %EJB_TEMP% 
    -outputfile DD.ser %DIRECTORY%\DeploymentDescriptor.txt

  6. Run ejbc on the DD.ser file, creating generated files:
    We can now generate all the code for the EJBean: 
      %JAVA% weblogic.ejbc -d %TEMP% %EJB_TEMP%\DD.ser

  7. Jar the EJBean using the manifest file:
    Change to the /temp directory, and jar up the EJBean, saving it in the /myserver directory: 
      pushd %TEMP%
  jar cmf ..\%EJB_DIRECTORY%\manifest ..\myserver\%JAR% %EJB_DIRECTORY%

  8. Remove the temp directory:
    Cleanup by deleting the contents of the temp directory and the directory, and then returning to the examples directory: 
      del /q %EJB_DIRECTORY%\*.*
  popd
  rmdir /s /q %TEMP%

Dependencies

With some of the examples (examples/cluster/ejb, examples/extensions and examples/subclass/child) there are dependencies that maust be checked for.