by
Ant provides a number of optional tasks for developing 1.x and 2.x Enterprise Java Beans (EJBs). In general these tasks are specific to the particular vendor's EJB Server.
The tasks support:
Vendors such as BEA and IBM now provide custom Ant tasks to work with their particular products. More importantly, EJB 3.0 renders this whole process obsolete. Accordingly, development of these tasks is effectively frozen. Bug reports and especially patches are welcome, but there is no pressing need to add support for new application servers. Nobody should be writing new EJB 2.x applications and definitely not new EJB 2.x servers.
| Task | Application Servers | |
|---|---|---|
| blgenclient | Borland Application Server 4.5 and 5.x | |
| iplanet-ejbc | iPlanet Application Server 6.0 | |
| ejbjar | Nested Elements | |
| borland | Borland Application Server 4.5 and 5.x | |
| iPlanet | iPlanet Application Server 6.0 | |
| jboss | JBoss | |
| jonas | JOnAS 2.4.x and 2.5 | |
| weblogic | WebLogic 5.1 to 7.0 | |
| websphere | IBM WebSphere 4.0 | |
| orion | IronFlare (Oracle) Orion Application Server 2.0.6 | |
ddcreator will compile a set of WebLogic text-based deployment descriptors into a
serialized EJB deployment descriptor. The selection of which of the text-based descriptors are to be
compiled is based on the standard Ant include and exclude selection
mechanisms.
| Attribute | Description | Required |
|---|---|---|
| descriptors | This is the base directory from which descriptors are selected. | Yes |
| dest | The directory where the serialized deployment descriptors will be written | Yes |
| classpath | This is the classpath to use to run the underlying WebLogic ddcreator tool.
This must include the weblogic.ejb.utils.DDCreator class |
No |
<ddcreator descriptors="${dd.dir}"
dest="${gen.classes}"
classpath="${descriptorbuild.classpath}">
<include name="*.txt"/>
</ddcreator>
The ejbc task will run WebLogic's ejbc tool. This tool will take a
serialized deployment descriptor, examine the various EJB interfaces and bean classes and then
generate the required support classes necessary to deploy the bean in a WebLogic EJB container. This
will include the RMI stubs and skeletons as well as the classes which implement the bean's home and
remote interfaces.
The Ant task which runs this tool is able to compile several beans in a single operation. The
beans to be compiled are selected by including their serialized deployment descriptors. The standard
Ant include and exclude constructs can be used to select the deployment
descriptors to be included.
Each descriptor is examined to determine whether the generated classes are out of date and need to be regenerated. The deployment descriptor is de-serialized to discover the home, remote and implementation classes. The corresponding source files are determined and checked to see their modification times. These times and the modification time of the serialized descriptor itself are compared with the modification time of the generated classes. If the generated classes are not present or are out of date, the ejbc tool is run to generate new versions.
| Attribute | Description | Required |
|---|---|---|
| descriptors | This is the base directory from which the serialized deployment descriptors are selected. | Yes |
| dest | The base directory where the generated classes, RIM stubs and RMI skeletons are written | Yes |
| manifest | The name of a manifest file to be written. This manifest will contain an entry for each EJB processed | Yes |
| src | The base directory of the source tree containing the source files of the home interface, remote interface and bean implementation classes. | Yes |
| classpath | This classpath must include both the weblogic.ejbc class and the class files of
the bean, home interface, remote interface, etc of the bean being processed. |
No |
| keepgenerated | Controls whether ejbc will keep the intermediate java files used to build the class files. This can be useful when debugging. | No; defaults to false |
<ejbc descriptors="${gen.classes}"
src="${src.dir}"
dest="${gen.classes}"
manifest="${build.manifest}"
classpath="${descriptorbuild.classpath}">
<include name="*.ser"/>
</ejbc>
Task to compile EJB stubs and skeletons for the iPlanet Application Server 6.0. Given a standard EJB 1.1 XML descriptor as well as an iAS-specific EJB descriptor, this task will generate the stubs and skeletons required to deploy the EJB to iAS. Since the XML descriptors can include multiple EJBs, this is a convenient way of specifying many EJBs in a single Ant task.
For each EJB specified, the task will locate the three classes that comprise the EJB in the destination directory. If these class files cannot be located in the destination directory, the task will fail. The task will also attempt to locate the EJB stubs and skeletons in this directory. If found, the timestamps on the stubs and skeletons will be checked to ensure they are up to date. Only if these files cannot be found or if they are out of date will the iAS ejbc utility be called to generate new stubs and skeletons.
| Attribute | Description | Required |
|---|---|---|
| ejbdescriptor | Standard EJB 1.1 XML descriptor (typically titled ejb-jar.xml). |
Yes |
| iasdescriptor | iAS-specific EJB XML descriptor (typically titled ias-ejb-jar.xml). |
Yes |
| dest | The is the base directory where the RMI stubs and skeletons are written. In addition, the class files for each bean (home interface, remote interface, and EJB implementation) must be found in this directory. | Yes |
| classpath | The classpath used when generating EJB stubs and skeletons. Nested classpath
elements may also be used. |
No; defaults to the classpath specified when Ant was started |
| keepgenerated | Indicates whether or not the Java source files which are generated by ejbc will
be saved or automatically deleted. If yes, the source files will be retained. |
No; defaults to no |
| debug | Indicates whether or not the ejbc utility should log additional debugging
statements to the standard output. If yes, the additional debugging statements will be generated. |
No; defaults to no |
| iashome | May be used to specify the "home" directory for this iAS installation. This is used to find the ejbc utility if it isn't included in the user's system path. If specified, it should refer to the [install-location]/iplanet/ias6/ias directory. | No; by default the ejbc utility must be on the user's system path |
<iplanet-ejbc ejbdescriptor="ejb-jar.xml"
iasdescriptor="ias-ejb-jar.xml"
dest="${build.classesdir}"
classpath="${ias.ejbc.cpath}"/>
<iplanet-ejbc ejbdescriptor="ejb-jar.xml"
iasdescriptor="ias-ejb-jar.xml"
dest="${build.classesdir}"
keepgenerated="yes"
debug="yes"
iashome="${ias.home}">
<classpath>
<pathelement path="."/>
<pathelement path="${build.classpath}"/>
</classpath>
</iplanet-ejbc>
The wlrun task is used to start a WebLogic server. The task runs a WebLogic instance
in a separate JVM. A number of parameters are used to control the operation of the WebLogic
instance. Note that the task, and hence Ant, will not complete until the WebLogic instance is
stopped.
| Attribute | Description | Required for 4.5.1 and 5.1 | Required for 6.0 |
|---|---|---|---|
| BEAhome | The location of the BEAhome where the server's config is stored. If this
attribute is present, wlrun assumes that the server will be running under
WebLogic 6.0 |
N/A | Yes |
| home | The location of the WebLogic "home" where WebLogic is installed. | Yes | Yes. Note this is the absolute location, not relative to BEAhome. |
| Domain | The domain to which the server belongs. | N/A | Yes |
| classpath | The classpath to be used with the JVM that runs the WebLogic Server. Prior to WebLogic 6.0, this is typically set to the WebLogic boot classpath. Under WebLogic 6.0 this should include all the WebLogic jars | Yes | |
| wlclasspath | The WebLogic classpath used by the WebLogic Server. | No | N/A |
| properties | The name of the server's properties file within the WebLogic home directory used to control the WebLogic instance. | Yes | |
| name | The name of the WebLogic server within the WebLogic home which is to be run. | No; defaults to myserver |
|
| policy | The name of the security policy file within the WebLogic home directory that is to be used. | No; defaults to weblogic.policy |
|
| username | The management username used to manage the server | N/A | No |
| password | The server's management password | Yes | |
| pkPassword | The private key password so the server can decrypt the SSL private key file | No | |
| jvmargs | Additional argument string passed to the JVM used to run the WebLogic instance. | No | |
| weblogicMainClass | The name of the main class for WebLogic | No | |
The wlrun task supports nested <classpath>
and <wlclasspath> elements to set the respective classpaths.
This example shows the use of wlrun to run a server under WebLogic 5.1
<wlrun taskname="myserver"
classpath="${weblogic.boot.classpath}"
wlclasspath="${weblogic.classes}:${code.jars}"
name="myserver"
home="${weblogic.home}"
properties="myserver/myserver.properties"/>
This example shows wlrun being used to run the petstore server under
WebLogic 6.0
<wlrun taskname="petstore"
classpath="${weblogic.classes}"
name="petstoreServer"
domain="petstore"
home="${weblogic.home}"
password="petstorePassword"
beahome="${bea.home}"/>
The wlstop task is used to stop a WebLogic instance which is currently running. To
shut down an instance you must supply both a username and a password. These will be stored in the
clear in the build script used to stop the instance. For security reasons, this task is therefore
only appropriate in a development environment.
This task works for most versions of WebLogic, including 6.0. You need to specify the BEAHome to have this task work correctly under 6.0
| Attribute | Description | Required |
|---|---|---|
| BEAHome | This attribute selects WebLogic 6.0 shutdown. | No |
| classpath | The classpath to be used with the JVM that runs the WebLogic Shutdown command. | Yes |
| user | The username of the account which will be used to shutdown the server | Yes |
| password | The password for the account specified in the user parameter. | Yes |
| url | The URL which describes the port to which the server is listening for T3 connections. For example, t3://localhost:7001 | Yes |
| delay | The delay in seconds after which the server will stop. | No; default is 0(immediate shutdown) |
The classpath of the wlstop task can be set by a <classpath>
nested element.
This example show the shutdown for a WebLogic 6.0 server
<wlstop classpath="${weblogic.classes}"
user="system"
url="t3://localhost:7001"
password="foobar"
beahome="${bea.home}"/>
This task is designed to support building of EJB jar files (EJB 1.1 & 2.0). Support is currently provided for 'vanilla' EJB jar files—i.e. those containing only the user generated class files and the standard deployment descriptor. Nested elements provide support for vendor specific deployment tools. These currently include:
weblogic.ejbc toolThe task works as a directory scanning task, and performs an action for each deployment
descriptor found. As such the includes and excludes should be set to
ensure that all desired EJB descriptors are found, but no application server descriptors are
found. For each descriptor found, ejbjar will parse the deployment descriptor to
determine the necessary class files which implement the bean. These files are assembled along with
the deployment descriptors into a well formed EJB jar file. Any support files which need to be
included in the generated jar can be added with the <support> nested element. For
each class included in the jar, ejbjar will scan for any super classes or super
interfaces. These will be added to the generated jar.
If no nested vendor-specific deployment elements are present, the task will simply generate a generic EJB jar. Such jars are typically used as the input to vendor-specific deployment tools. For each nested deployment element, a vendor specific deployment tool is run to generate a jar file ready for deployment in that vendor's EJB container.
The jar files are only built if they are out of date. Each deployment tool element will examine its target jar file and determine if it is out of date with respect to the class files and deployment descriptors that make up the bean. If any of these files are newer than the jar file the jar will be rebuilt otherwise a message is logged that the jar file is up to date.
The task uses the BCEL library to extract all dependent classes. This means that, in addition to the classes that are mentioned in the deployment descriptor, any classes that these depend on are also automatically included in the jar file.
Ejbjar handles the processing of multiple beans, and it uses a set of naming
conventions to determine the name of the generated EJB jars. The naming convention that is used is
controlled by the naming attribute. It supports the following values
descriptor
This is the default naming scheme. The name of the generated bean is derived from the name of the deployment descriptor. For an Account bean, for example, the deployment descriptor would be named Account-ejb-jar.xml. Vendor specific descriptors are located using the same naming convention. The WebLogic bean, for example, would be named Account-weblogic-ejb-jar.xml. Under this arrangement, the deployment descriptors can be separated from the code implementing the beans, which can be useful when the same bean code is deployed in separate beans.
This scheme is useful when you are using one bean per EJB jar and where you may be deploying the same bean classes in different beans, with different deployment characteristics.
ejb-name
This naming scheme uses the <ejb-name> element from the deployment
descriptor to determine the bean name. In this situation, the descriptors normally use the generic
descriptor names, such as ejb-jar.xml along with any associated vendor specific
descriptor names. For example, If the value of the <ejb-name> were to be given in
the deployment descriptor as follows:
<ejb-jar>
<enterprise-beans>
<entity>
<ejb-name>Sample</ejb-name>
<home>org.apache.ant.ejbsample.SampleHome</home>
then the name of the generated bean would be Sample.jar
This scheme is useful where you want to use the standard deployment descriptor names, which may be more compatible with other EJB tools. This scheme must have one bean per jar.
directory
In this mode, the name of the generated bean jar is derived from the directory containing the deployment descriptors. Again the deplo