diff options
Diffstat (limited to 'framework/src/ant/apache-ant-1.9.6/manual/Tasks/ejb.html')
| -rw-r--r-- | framework/src/ant/apache-ant-1.9.6/manual/Tasks/ejb.html | 1777 |
1 files changed, 1777 insertions, 0 deletions
diff --git a/framework/src/ant/apache-ant-1.9.6/manual/Tasks/ejb.html b/framework/src/ant/apache-ant-1.9.6/manual/Tasks/ejb.html new file mode 100644 index 00000000..aa140e70 --- /dev/null +++ b/framework/src/ant/apache-ant-1.9.6/manual/Tasks/ejb.html @@ -0,0 +1,1777 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. +--> +<html> + +<head> +<meta http-equiv="Content-Language" content="en-us"> +<link rel="stylesheet" type="text/css" href="../stylesheets/style.css"> +<title>EJB Tasks</title> + +</head> + +<body> + +<h1>Apache Ant EJB Tasks User Manual</h1> +<p>by</p> +<!-- Names are in alphabetical order, on last name --> +<ul> + <li>Paul Austin (<a href="mailto:p_d_austin@yahoo.com">p_d_austin@yahoo.com</a>)</li> + <li>Holger Engels (<a href="mailto:hengels@innovidata.com">hengels@innovidata.com</a>)</li> + <li>Tim Fennell (<a href="mailto:tfenne@rcn.com">tfenne@rcn.com</a>)</li> + <li>Martin Gee (<a href="mailto:martin.gee@icsynergy.com">martin.gee@icsynergy.com</a>)</li> + <li>Conor MacNeill</li> + <li>Cyrille Morvan (<a href="mailto:cmorvan@ingenosya.com">cmorvan@ingenosya.com</a>)</li> + <li>Greg Nelson (<a href="mailto:gn@sun.com">gn@sun.com</a>)</li> + <li>Rob van Oostrum(<a href="mailto:rob@springwellfarms.ca">rob@springwellfarms.ca</a>)</li> +</ul> + +<hr> +<h2>Table of Contents</h2> +<ul> + <li><a href="#introduction">Introduction</a></li> + <li><a href="#ejbtasks">EJB Tasks</a></li> +</ul> + +<hr> +<h2><a name="introduction">Introduction</a></h2> +<p>Ant provides a number of optional tasks for developing 1.x and 2.x +<a href="http://www.oracle.com/technetwork/java/index-jsp-140203.html" target="_top">Enterprise Java Beans (EJBs)</a>. +In general these tasks are specific to the particular vendor's EJB Server.</p> + +<p> The tasks support:<br> + +<ul> + <li><a href="http://www.borland.com">Borland </a> + Application Server 4.5</li> + <li><a href="http://www.iplanet.com">iPlanet </a> + Application Server 6.0</li> + <li><a href="http://www.jboss.org/" target="_top"> + JBoss 2.1</a> and above EJB servers</li> + <li><a href="http://www.bea.com" target="_top">Weblogic</a> + 4.5.1 through to 7.0 EJB servers</li> + <li><a href="http://www.objectweb.org/jonas/" target="_top">JOnAS</a> + 2.4.x and 2.5 Open Source EJB server</li> + <li><a href="http://www.ibm.com/websphere">IBM WebSphere</a> 4.0</li> +</ul> + Vendors such as BEA and IBM now provide custom Ant tasks to work with their + particular products. More importantly, EJB3.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 EJB2.x applications + and definitely not new EJB2.x servers. +</p> + +<hr> +<h2><a name="ejbtasks">EJB Tasks</a></h2> +<table border="1" cellpadding="5"> + <tr><td>Task</td><td colspan="2">Application Servers</td></tr> + <tr><td><a href="BorlandGenerateClient.html">blgenclient</a></td><td colspan="2">Borland Application Server 4.5 and 5.x</td></tr> + <tr><td><a href="#iplanet-ejbc">iplanet-ejbc</a></td><td colspan="2">iPlanet Application Server 6.0</td></tr> + <tr><td rowspan="7"><a href="#ejbjar">ejbjar</a></td><td colspan="2" align="center"><b>Nested Elements</b></td></tr> + <tr><td><a href="BorlandEJBTasks.html">borland</a></td><td>Borland Application Server 4.5 and 5.x</td></tr> + <tr><td><a href="#ejbjar_iplanet">iPlanet</a></td><td>iPlanet Application Server 6.0</td></tr> + <tr><td><a href="#ejbjar_jboss">jboss</a></td><td>JBoss</td></tr> + <tr><td><a href="#ejbjar_jonas">jonas</a></td><td>JOnAS 2.4.x and 2.5</td></tr> + <tr><td><a href="#ejbjar_weblogic">weblogic</a></td><td>Weblogic 5.1 to 7.0</td></tr> + <tr><td><a href="#ejbjar_websphere">websphere</a></td><td>IBM WebSphere 4.0</td></tr> + +</table> + +<hr> +<h2><a name="ddcreator">ddcreator</a></h2> +<h3><b>Description:</b></h3> +<p>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. +</p> + +<h3>Parameters:</h3> +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">descriptors</td> + <td valign="top">This is the base directory from which descriptors are selected.</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">dest</td> + <td valign="top">The directory where the serialized deployment descriptors will be written</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">classpath</td> + <td valign="top">This is the classpath to use to run the underlying weblogic ddcreator tool. + This must include the <code>weblogic.ejb.utils.DDCreator</code> class</td> + <td valign="top" align="center">No</td> + </tr> +</table> +<h3>Examples</h3> +<pre> +<ddcreator descriptors="${dd.dir}" + dest="${gen.classes}" + classpath="${descriptorbuild.classpath}"> + <include name="*.txt"/> +</ddcreator> +</pre> + +<hr> +<h2><a name="ejbc">ejbc</a></h2> +<h3><b>Description:</b></h3> +<p>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.</p> +<p> +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 +<code>include</code> and <code>exclude</code> constructs can be used to select the deployment descriptors +to be included. </p> +<p> +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.</p> +<h3>Parameters:</h3> +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">descriptors</td> + <td valign="top">This is the base directory from which the serialized deployment descriptors are selected.</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">dest</td> + <td valign="top">The base directory where the generated classes, RIM stubs and RMI skeletons are written</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">manifest</td> + <td valign="top">The name of a manifest file to be written. This manifest will contain an entry for each EJB processed</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">src</td> + <td valign="top">The base directory of the source tree containing the source files of the home interface, + remote interface and bean implementation classes.</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">classpath</td> + <td valign="top">This classpath must include both the <code>weblogic.ejbc</code> class and the + class files of the bean, home interface, remote interface, etc of the bean being + processed.</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">keepgenerated</td> + <td>Controls whether ejbc will keep the + intermediate Java files used to build the class files. This can be + useful when debugging.</td> + <td>No, defaults to false.</td> + </tr> +</table> +<h3>Examples</h3> +<pre> +<ejbc descriptors="${gen.classes}" + src="${src.dir}" + dest="${gen.classes}" + manifest="${build.manifest}" + classpath="${descriptorbuild.classpath}"> + <include name="*.ser"/> +</ejbc> +</pre> + +<hr> +<h2> +<a NAME="iplanet-ejbc"></a>iplanet-ejbc</h2> + +<h3> +<b>Description:</b></h3> +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. +<p>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.</p> +<h3> +Parameters:</h3> + +<table border="1" cellspacing="0" cellpadding="2"> +<tr> +<td valign="top"><b>Attribute</b></td> + +<td valign="top"><b>Description</b></td> + +<td align="center" valign="top"><b>Required</b></td> +</tr> + +<tr> +<td valign="top">ejbdescriptor</td> + +<td valign="top">Standard EJB 1.1 XML descriptor (typically titled "ejb-jar.xml").</td> + +<td align="center" valign="top">Yes</td> +</tr> + +<tr> +<td valign="top">iasdescriptor</td> + +<td valign="top">iAS-specific EJB XML descriptor (typically titled "ias-ejb-jar.xml").</td> + +<td align="center" valign="top">Yes</td> +</tr> + +<tr> +<td valign="top">dest</td> + +<td valign="top">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.</td> + +<td align="center" valign="top">Yes</td> +</tr> + +<tr> +<td valign="top">classpath</td> + +<td valign="top">The classpath used when generating EJB stubs and skeletons. +If omitted, the classpath specified when Ant was started will be used. +Nested "classpath" elements may also be used.</td> + +<td align="center" valign="top">No</td> +</tr> + +<tr> +<td valign="top">keepgenerated</td> + +<td valign="top">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. If omitted, it defaults to "no". </td> + +<td align="center" valign="top">No</td> +</tr> + +<tr> +<td valign="top">debug</td> + +<td>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. If omitted, it defaults to "no". </td> + +<td align="center" valign="top"> +<center>No</center> +</td> +</tr> + +<tr> +<td valign="top">iashome</td> + +<td>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. If omitted, the ejbc utility must be on the user's system path. </td> + +<td align="center" valign="top">No</td> +</tr> +</table> + +<h3> +Examples</h3> + +<pre> +<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> + + +</pre> + +<hr> +<h2><a name="wlrun">wlrun</a></h2> +<h3><b>Description:</b></h3> + +<p>The <code>wlrun</code> task is used to start a weblogic server. The task runs +a weblogic instance in a separate Java Virtual Machine. 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.</p> + +<h3>Parameters:</h3> +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required for 4.5.1 and 5.1</b></td> + <td align="center" valign="top"><b>Required for 6.0</b></td> + </tr> + <tr> + <td valign="top">BEA Home</td> + <td valign="top">The location of the BEA Home where the server's config is defined. + If this attribute is present, wlrun assumes that the server will + be running under Weblogic 6.0</td> + <td valign="top" align="center">N/A</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">home</td> + <td valign="top">The location of the weblogic home that is to be used. This is the location + where weblogic is installed.</td> + <td valign="top" align="center">Yes</td> + <td valign="top" align="center">Yes. Note this is the absolute location, not relative to + BEA home.</td> + </tr> + <tr> + <td valign="top">Domain</td> + <td valign="top">The domain to which the server belongs.</td> + <td valign="top" align="center">N/A</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">classpath</td> + <td valign="top">The classpath to be used with the Java Virtual Machine 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</td> + <td valign="top" align="center">Yes</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">wlclasspath</td> + <td valign="top">The weblogic classpath used by the Weblogic Server.</td> + <td valign="top" align="center">No</td> + <td valign="top" align="center">N/A</td> + </tr> + <tr> + <td valign="top">properties</td> + <td valign="top">The name of the server's properties file within the weblogic home directory + used to control the weblogic instance.</td> + <td valign="top" align="center">Yes</td> + <td valign="top" align="center">N/A</td> + </tr> + <tr> + <td valign="top">name</td> + <td valign="top">The name of the weblogic server within the weblogic home which is to be run. + This defaults to "myserver"</td> + <td valign="top" align="center">No</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">policy</td> + <td valign="top">The name of the security policy file within the weblogic home directory that + is to be used. If not specified, the default policy file <code>weblogic.policy</code> + is used.</td> + <td valign="top" align="center">No</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">username</td> + <td valign="top">The management username used to manage the server</td> + <td valign="top" align="center">N/A</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">password</td> + <td valign="top">The server's management password</td> + <td valign="top" align="center">N/A</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">pkPassword</td> + <td valign="top">The private key password so the server can decrypt the SSL + private key file</td> + <td valign="top" align="center">N/A</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">jvmargs</td> + <td valign="top">Additional argument string passed to the Java Virtual Machine used to run the + Weblogic instance.</td> + <td valign="top" align="center">No</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">weblogicMainClass</td> + <td valign="top">name of the main class for weblogic</td> + <td valign="top" align="center">No</td> + <td valign="top" align="center">No</td> + </tr> +</table> + +<h3>Nested Elements</h3> + +<p>The wlrun task supports nested <code><classpath></code> and <code><wlclasspath></code> +elements to set the respective classpaths.</p> + +<h3>Examples</h3> + +<p>This example shows the use of wlrun to run a server under Weblogic 5.1</p> + +<pre> + <wlrun taskname="myserver" + classpath="${weblogic.boot.classpath}" + wlclasspath="${weblogic.classes}:${code.jars}" + name="myserver" + home="${weblogic.home}" + properties="myserver/myserver.properties"/> +</pre> + +<p>This example shows wlrun being used to run the petstore server under +Weblogic 6.0</p> + +<pre> + <wlrun taskname="petstore" + classpath="${weblogic.classes}" + name="petstoreServer" + domain="petstore" + home="${weblogic.home}" + password="petstorePassword" + beahome="${bea.home}"/> +</pre> + +<hr> +<h2><a name="wlstop">wlstop</a></h2> +<h3><b>Description:</b></h3> + +<p>The <code>wlstop</code> 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. </p> + +<p>This task works for most version of Weblogic, including 6.0. You need to +specify the BEA Home to have this task work correctly under 6.0</p> + +<h3>Parameters:</h3> +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">BEAHome</td> + <td valign="top">This attribute selects Weblogic 6.0 shutdown.</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">classpath</td> + <td valign="top">The classpath to be used with the Java Virtual Machine that runs the Weblogic + Shutdown command.</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">user</td> + <td valign="top">The username of the account which will be used to shutdown the server</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">password</td> + <td valign="top">The password for the account specified in the user parameter.</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">url</td> + <td valign="top">The URL which describes the port to which the server is listening for T3 connections. + For example, t3://localhost:7001</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">delay</td> + <td valign="top">The delay in seconds after which the server will stop. This defaults to an + immediate shutdown.</td> + <td valign="top" align="center">No</td> + </tr> +</table> + +<h3>Nested Element</h3> + +<p>The classpath of the wlstop task can be set by a <code><classpath></code> nested element.</p> + +<h3>Examples</h3> + +<p>This example show the shutdown for a Weblogic 6.0 server</p> + +<pre> + <wlstop classpath="${weblogic.classes}" + user="system" + url="t3://localhost:7001" + password="foobar" + beahome="${bea.home}"/> +</pre> + +<hr> + +<h2><a name="ejbjar">ejbjar</a></h2> +<h3><b>Description:</b></h3> + +<p>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: </p> +<ul> + <li>Borland Application Server 4.5</li> + <li>iPlanet Application Server 6.0</li> + <li>JBoss 2.1 and above</li> + <li>Weblogic 5.1/6.0 session/entity beans using the weblogic.ejbc tool</li> + <li>IBM WebSphere 4.0</li> + <li>TOPLink for WebLogic 2.5.1-enabled entity beans</li> + <li><a href="http://www.objectweb.org/jonas/">JOnAS</a> 2.4.x and 2.5 Open Source EJB server</li> +</ul> + + +<p>The 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 <code><support></code> 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.</p> + +<p>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. </p> + +<p>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.</p> + +<p>The task uses the +<a href="http://commons.apache.org/bcel/"> BCEL </a> framework +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.</p> + + +<h3>Naming Convention</h3> + +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 +<ul> + +<li>descriptor</li> +<p>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 <code>Account-ejb-jar.xml</code>. Vendor specific descriptors are +located using the same naming convention. The weblogic bean, for example, would be named +<code>Account-weblogic-ejb-jar.xml</code>. 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. +</p> + +<p>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. + +<li>ejb-name</li> +<p> This naming scheme uses the <code><ejb-name></code> element from the deployment descriptor to +determine the bean name. In this situation, the descriptors normally use the generic +descriptor names, such as <code>ejb-jar.xml</code> along with any associated vendor specific descriptor +names. For example, If the value of the <code><ejb-name></code> were to be given in the deployment descriptor +as follows: +<pre> +<ejb-jar> + <enterprise-beans> + <entity> + <ejb-name>Sample</ejb-name> + <home>org.apache.ant.ejbsample.SampleHome</home> +</pre> + +then the name of the generated bean would be <code>Sample.jar</code> +</p> +<p> 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. +</p> +<li>directory</li> +<p> +In this mode, the name of the generated bean jar is derived from the directory +containing the deployment descriptors. Again the deployment descriptors typically use +the standard filenames. For example, if the path to the deployment descriptor is +<code>/home/user/dev/appserver/dd/sample</code>, then the generated +bean will be named <code>sample.jar</code> +</p> +<p> +This scheme is also useful when you want to use standard style descriptor names. It is often +most useful when the descriptors are located in the same directory as the bean source code, +although that is not mandatory. This scheme can handle multiple beans per jar. +</p> + +<li>basejarname</li> +<p> +The final scheme supported by the <code><ejbjar></code> task is used when you want to specify the generated +bean jar name directly. In this case the name of the generated jar is specified by the +"basejarname" attribute. Since all generated beans will have the same name, this task should +be only used when each descriptor is in its own directory. +</p> + +<p> +This scheme is most appropriate when you are using multiple beans per jar and only process a single +deployment descriptor. You typically want to specify the name of the jar and not derive it from the +beans in the jar. +</p> + +</ul> + +<a name="ejbjar_deps"><h3>Dependencies</h3></a> +<p>In addition to the bean classes, ejbjar is able to ad additional classes to the generated +ejbjar. These classes are typically the support classes which are used by the bean's classes or as +parameters to the bean's methods.</p> + +<p>In versions of Ant prior to 1.5, ejbjar used reflection and attempted to add the super +classes and super interfaces of the bean classes. For this technique to work the bean +classes had to be loaded into Ant's JVM. This was not always possible due to class dependencies. +</p> + +<p>The ejbjar task in Ant releases 1.5 and later uses the +<a href="http://commons.apache.org/bcel/"> BCEL </a> library +to analyze the bean's class +files directly, rather than loading them into the JVM. This also allows ejbjar to add all +of the required support classes for a bean and not just super classes. +</p> + +<p>In Ant 1.5, a new attribute, <code>dependency</code> has been introduced to allow the +buildfile to control what additional classes are added to the generated jar. It takes three +possible values</p> +<ul> +<li><code>none</code> - only the bean classes and interfaces described in the bean's +descriptor are added to the jar.</li> +<li><code>super</code> - this is the default value and replicates the original ejbjar +behaviour where super classes and super interfaces are added to the jar</li> +<li><code>full</code> - In this mode all classes used by the bean's classes and interfaces +are added to the jar</li> +</ul> +<p>The <code>super</code> and <code>full</code> values require the +<a href="http://commons.apache.org/bcel/"> BCEL </a> library +to be available. If it is not, ejbjar will drop back to the behaviour corresponding to +the value <code>none</code>.</p> + +<h3>Parameters:</h3> +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">descriptordir</td> + <td valign="top">The base directory under which to scan for EJB + deployment descriptors. If this attribute is not + specified, then the deployment descriptors must be + located in the directory specified by the 'srcdir' + attribute.</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">srcdir</td> + <td valign="top">The base directory containing the .class files that + make up the bean. Included are the home- remote- pk- + and implementation- classes and all classes, that these + depend on. Note that this can be the same as the + descriptordir if all files are in the same directory + tree.</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">destdir</td> + <td valign="top">The base directory into which generated jar files are + deposited. Jar files are deposited in directories + corresponding to their location within the descriptordir + namespace. Note that this attribute is only used if the + task is generating generic jars (i.e. no vendor-specific + deployment elements have been specified).</td> + <td valign="top" align="center">Yes, unless vendor-specific deployment elements + have been specified.</td> + </tr> + <tr> + <td valign="top">cmpversion</td> + <td valign="top">Either <code>1.0</code> or <code>2.0</code>.<br> + Default is <code>1.0</code>.<br> + A CMP 2.0 implementation exists currently only for JBoss.</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">naming</td> + <td valign="top">Controls the naming convention used to name generated + EJB jars. Please refer to the description above.</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">basejarname</td> + <td valign="top">The base name that is used for the generated jar files. + If this attribute is specified, the generic jar file name + will use this value as the prefix (followed by the value + specified in the 'genericjarsuffix' attribute) and the + resultant ejb jar file (followed by any suffix specified + in the nested element).</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">basenameterminator</td> + <td valign="top">String value used to substring out a string from the name + of each deployment descriptor found, which is then used to + locate related deployment descriptors (e.g. the WebLogic + descriptors). For example, a basename of '.' and a + deployment descriptor called 'FooBean.ejb-jar.xml' would + result in a basename of 'FooBean' which would then be used + to find FooBean.weblogic-ejb-jar.xml and + FooBean.weblogic-cmp-rdbms-jar.xml, as well as to create + the filenames of the jar files as FooBean-generic.jar and + FooBean-wl.jar. This attribute is not used if the + 'basejarname' attribute is specified.</td> + <td valign="top" align="center">No, defaults to '-'.</td> + </tr> + <tr> + <td valign="top">genericjarsuffix</td> + <td valign="top">String value appended to the basename of the deployment + descriptor to create the filename of the generic EJB jar + file.</td> + <td valign="top" align="center">No, defaults to '-generic.jar'.</td> + </tr> + <tr> + <td valign="top">classpath</td> + <td valign="top">This classpath is used when resolving classes which + are to be added to the jar. Typically nested deployment + tool elements will also support a classpath which + will be combined with this classpath when resolving + classes</td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">flatdestdir</td> + <td valign="top">Set this attribute to true if you want all generated jars + to be placed in the root of the destdir, rather than + according to the location of the deployment descriptor + within the descriptor dir hierarchy.</td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">dependency</td> + <td valign="top">This attribute controls which additional classes and interfaces + are added to the jar. Please refer to the description + <a href="#ejbjar_deps">above</a></td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">manifest</td> + <td valign="top">the manifest file to use, if any.</td> + <td valign="top" align="center">No</td> + </tr> +</table> + +<h3>Nested Elements</h3> + +<p>In addition to the vendor specific nested elements, the ejbjar task provides +three nested elements. </p> + +<h4>Classpath</h4> + +<p>The <code><classpath></code> nested element allows the classpath +to be set. It is useful when setting the classpath from a reference path. In all +other respects the behaviour is the same as the classpath attribute.</p> + +<a name="ejbjar-dtd"><h4>dtd</h4></a> + +<p>The <code><dtd></code> element is used to specify the local location of DTDs to be +used when parsing the EJB deployment descriptor. Using a local DTD is much +faster than loading the DTD across the net. If you are running ejbjar behind a +firewall you may not even be able to access the remote DTD. The supported +vendor-specific nested elements know the location of the required DTDs within +the vendor class hierarchy and, in general, this means <code><dtd></code> elements are +not required. It does mean, however, that the vendor's class hierarchy must be +available in the classpath when Ant is started. If your want to run Ant without +requiring the vendor classes in the classpath, you would need to use a +<code><dtd></code> element.</p> + +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">publicId</td> + <td valign="top">The public Id of the DTD for which the location is being provided</td> + <td align="center" valign="top">Yes</td> + </tr> + <tr> + <td valign="top">location</td> + <td valign="top">The location of the local copy of the DTD. This can either be a + file or a resource loadable from the classpath.</td> + <td align="center" valign="top">Yes</td> + </tr> +</table> + +<h4>support</h4> + +<p>The <code><support></code> nested element is used to supply additional classes +(files) to be included in the generated jars. The <code><support></code> element is a +<a href="../Types/fileset.html">FileSet</a>, so it can either reference a fileset declared elsewhere or it can be +defined in-place with the appropriate <code><include></code> and <code><exclude></code> nested +elements. The files in the support fileset are added into the generated EJB jar +in the same relative location as their location within the support fileset. Note +that when ejbjar generates more than one jar file, the support files are added +to each one.</p> + +<h3>Vendor-specific deployment elements</h3> + +Each vendor-specific nested element controls the generation of a deployable jar +specific to that vendor's EJB container. The parameters for each supported +deployment element are detailed here. + + +<h3><a name="ejbjar_jboss">Jboss element</a></h3> + +<p>The jboss element searches for the JBoss specific deployment descriptors and adds them +to the final ejb jar file. JBoss has two deployment descriptors: +<ul><li>jboss.xml</li> +<li>for container manager persistence:<br> +<table border="1"> +<tr><td><b>CMP version</b></td><td><b>File name</b></td></tr> +<tr><td>CMP 1.0</td><td>jaws.xml</td></tr> +<tr><td>CMP 2.0</td><td>jbosscmp-jdbc.xml</td></tr> +</table> +</li> +</ul> +<br> +. The JBoss server uses hot deployment and does +not require compilation of additional stubs and skeletons.</p> + +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">destdir</td> + <td valign="top">The base directory into which the generated weblogic ready + jar files are deposited. Jar files are deposited in + directories corresponding to their location within the + descriptordir namespace. </td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">genericjarsuffix</td> + <td valign="top">A generic jar is generated as an intermediate step in + build the weblogic deployment jar. The suffix used to + generate the generic jar file is not particularly + important unless it is desired to keep the generic + jar file. It should not, however, be the same + as the suffix setting.</td> + <td valign="top" align="center">No, defaults to '-generic.jar'.</td> + </tr> + <tr> + <td valign="top">suffix</td> + <td valign="top">String value appended to the basename of the deployment + descriptor to create the filename of the JBoss EJB + jar file.</td> + <td valign="top" align="center">No, defaults to '.jar'.</td> + </tr> + <tr> + <td valign="top">keepgeneric</td> + <td valign="top">This controls whether the generic file used as input to + ejbc is retained.</td> + <td valign="top" align="center">No, defaults to false</td> + </tr> +</table> + + +<h3><a name="ejbjar_weblogic">Weblogic element</a></h3> + +<p>The weblogic element is used to control the weblogic.ejbc compiler for +generating weblogic EJB jars. Prior to Ant 1.3, the method of locating CMP +descriptors was to use the ejbjar naming convention. So if your ejb-jar was +called, Customer-ejb-jar.xml, your weblogic descriptor was called Customer- +weblogic-ejb-jar.xml and your CMP descriptor had to be Customer-weblogic-cmp- +rdbms-jar.xml. In addition, the <code><type-storage></code> element in the weblogic +descriptor had to be set to the standard name META-INF/weblogic-cmp-rdbms- +jar.xml, as that is where the CMP descriptor was mapped to in the generated +jar.</p> + +<p>There are a few problems with this scheme. It does not allow for more than +one CMP descriptor to be defined in a jar and it is not compatible with the +deployment descriptors generated by some tools.</p> + +<p>In Ant 1.3, ejbjar parses the weblogic deployment descriptor to discover the +CMP descriptors, which are then included automatically. This behaviour is +controlled by the newCMP attribute. Note that if you move to the new method of +determining CMP descriptors, you will need to update your weblogic deployment +descriptor's <code><type-storage></code> element. In the above example, you would +define this as META-INF/Customer-weblogic-cmp-rdbms-jar.xml.</p> + +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">destdir</td> + <td valign="top">The base directory into which the generated weblogic ready + jar files are deposited. Jar files are deposited in + directories corresponding to their location within the + descriptordir namespace. </td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">genericjarsuffix</td> + <td valign="top">A generic jar is generated as an intermediate step in + build the weblogic deployment jar. The suffix used to + generate the generic jar file is not particularly + important unless it is desired to keep the generic + jar file. It should not, however, be the same + as the suffix setting.</td> + <td valign="top" align="center">No, defaults to '-generic.jar'.</td> + </tr> + <tr> + <td valign="top">suffix</td> + <td valign="top">String value appended to the basename of the deployment + descriptor to create the filename of the WebLogic EJB + jar file.</td> + <td valign="top" align="center">No, defaults to '.jar'.</td> + </tr> + <tr> + <td valign="top">classpath</td> + <td valign="top">The classpath to be used when running the weblogic ejbc + tool. Note that this tool typically requires the classes + that make up the bean to be available on the classpath. + Currently, however, this will cause the ejbc tool to be + run in a separate VM</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">wlclasspath</td> + <td valign="top">Weblogic 6.0 will give a warning if the home and remote interfaces + of a bean are on the system classpath used to run weblogic.ejbc. + In that case, the standard weblogic classes should be set with + this attribute (or equivalent nested element) and the + home and remote interfaces located with the standard classpath + attribute</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">keepgeneric</td> + <td valign="top">This controls whether the generic file used as input to + ejbc is retained.</td> + <td valign="top" align="center">No, defaults to false</td> + </tr> + <tr> + <td valign="top">compiler</td> + <td valign="top">This allows for the selection of a different compiler + to be used for the compilation of the generated Java + files. This could be set, for example, to Jikes to + compile with the Jikes compiler. If this is not set + and the <code>build.compiler</code> property is set + to jikes, the Jikes compiler will be used. If this + is not desired, the value "<code>default</code>" + may be given to use the default compiler</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">rebuild</td> + <td valign="top">This flag controls whether weblogic.ejbc is always + invoked to build the jar file. In certain circumstances, + such as when only a bean class has been changed, the jar + can be generated by merely replacing the changed classes + and not rerunning ejbc. Setting this to false will reduce + the time to run ejbjar. + </td> + <td valign="top" align="center">No, defaults to true.</td> + </tr> + <tr> + <td valign="top">keepgenerated</td> + <td valign="top">Controls whether weblogic will keep the generated Java + files used to build the class files added to the + jar. This can be useful when debugging + </td> + <td valign="top" align="center">No, defaults to false.</td> + </tr> + <tr> + <td valign="top">args</td> + <td valign="top">Any additional arguments to be passed to the weblogic.ejbc + tool. + </td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">weblogicdtd</td> + <td valign="top"><b>Deprecated</b>. Defines the location of the ejb-jar DTD in + the weblogic class hierarchy. This should not be necessary if you + have weblogic in your classpath. If you do not, you should use a + nested <code><dtd></code> element, described above. If you do choose + to use an attribute, you should use a + nested <code><dtd></code> element. + </td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">wldtd</td> + <td valign="top"><b>Deprecated</b>. Defines the location of the weblogic-ejb-jar + DTD which covers the Weblogic specific deployment descriptors. + This should not be necessary if you have weblogic in your + classpath. If you do not, you should use a nested <code><dtd></code> + element, described above. + </td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">ejbdtd</td> + <td valign="top"><b>Deprecated</b>. Defines the location of the ejb-jar DTD in + the weblogic class hierarchy. This should not be necessary if you + have weblogic in your classpath. If you do not, you should use a + nested <code><dtd></code> element, described above. + </td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">newCMP</td> + <td valign="top">If this is set to true, the new method for locating + CMP descriptors will be used.</td> + <td valign="top" align="center">No. Defaults to false</td> + </tr> + <tr> + <td valign="top">oldCMP</td> + <td valign="top"><b>Deprecated</b> This is an antonym for newCMP which should be used instead.</td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">noEJBC</td> + <td valign="top">If this attribute is set to true, Weblogic's ejbc will not be run on the EJB jar. + Use this if you prefer to run ejbc at deployment time.</td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">ejbcclass</td> + <td valign="top">Specifies the classname of the ejbc compiler. Normally ejbjar determines + the appropriate class based on the DTD used for the EJB. The EJB 2.0 compiler + featured in weblogic 6 has, however, been deprecated in version 7. When + using with version 7 this attribute should be set to + "weblogic.ejbc" to avoid the deprecation warning.</td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">jvmargs</td> + <td valign="top">Any additional arguments to be passed to the Virtual Machine + running weblogic.ejbc tool. For example to set the memory size, + this could be jvmargs="-Xmx128m" + </td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">jvmdebuglevel</td> + <td valign="top">Sets the weblogic.StdoutSeverityLevel to use when running + the Virtual Machine that executes ejbc. Set to 16 to avoid + the warnings about EJB Home and Remotes being in the classpath + </td> + <td valign="top" align="center">No.</td> + </tr> + <tr> + <td valign="top">outputdir</td> + <td valign="top">If set ejbc will be given this directory as the output + destination rather than a jar file. This allows for the + generation of "exploded" jars. + </td> + <td valign="top" align="center">No.</td> + </tr> +</table> + +<p>The weblogic nested element supports three nested elements. The +first two, <code><classpath></code> and <code><wlclasspath></code>, are used to set the +respective classpaths. These nested elements are useful when setting up +class paths using reference Ids. The last, <code><sysproperty></code>, allows +Java system properties to be set during the compiler run. This turns out +to be necessary for supporting CMP EJB compilation in all environments. +</p> + +<h3>TOPLink for Weblogic element</h3> + +<p><b><i>Deprecated</i></b></p> + +<p>The toplink element is no longer required. Toplink beans can now be built with the standard +weblogic element, as long as the newCMP attribute is set to "true" +</p> + +<p>The TopLink element is used to handle beans which use Toplink for the CMP operations. It +is derived from the standard weblogic element so it supports the same set of attributes plus these +additional attributes</p> + +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">toplinkdescriptor</td> + <td valign="top">This specifies the name of the TOPLink deployment descriptor file contained in the + 'descriptordir' directory.</td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">toplinkdtd</td> + <td valign="top">This specifies the location of the TOPLink DTD file. This can be a file path or + a file URL. This attribute is not required, but using a local DTD is recommended.</td> + <td valign="top" align="center">No, defaults to dtd file at www.objectpeople.com.</td> + </tr> +</table> + + +<h3>Examples</h3> + +<p>This example shows ejbjar being used to generate deployment jars using a +Weblogic EJB container. This example requires the naming standard to be used for +the deployment descriptors. Using this format will create a ejb jar file for +each variation of '*-ejb-jar.xml' that is found in the deployment descriptor +directory.</p> + +<pre> + <ejbjar srcdir="${build.classes}" + descriptordir="${descriptor.dir}"> + <weblogic destdir="${deploymentjars.dir}" + classpath="${descriptorbuild.classpath}"/> + <include name="**/*-ejb-jar.xml"/> + <exclude name="**/*weblogic*.xml"/> + </ejbjar> +</pre> + +<p>If weblogic is not in the Ant classpath, the following example +shows how to specify the location of the weblogic DTDs. This +example also show the use of a nested classpath element.</p> + +<pre> + <ejbjar descriptordir="${src.dir}" srcdir="${build.classes}"> + <weblogic destdir="${deployment.webshop.dir}" + keepgeneric="true" + args="-g -keepgenerated ${ejbc.compiler}" + suffix=".jar" + oldCMP="false"> + <classpath> + <pathelement path="${descriptorbuild.classpath}"/> + </classpath> + </weblogic> + <include name="**/*-ejb-jar.xml"/> + <exclude name="**/*-weblogic-ejb-jar.xml"/> + <dtd publicId="-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN" + location="${weblogic.home}/classes/weblogic/ejb/deployment/xml/ejb-jar.dtd"/> + <dtd publicId="-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN" + location="${weblogic.home}/classes/weblogic/ejb/deployment/xml/weblogic-ejb-jar.dtd"/> + </ejbjar> +</pre> + + +<p>This example shows ejbjar being used to generate a single deployment jar +using a Weblogic EJB container. This example does not require the deployment +descriptors to use the naming standard. This will create only one ejb jar file - +'TheEJBJar.jar'.</p> + + +<pre> + <ejbjar srcdir="${build.classes}" + descriptordir="${descriptor.dir}" + basejarname="TheEJBJar"> + <weblogic destdir="${deploymentjars.dir}" + classpath="${descriptorbuild.classpath}"/> + <include name="**/ejb-jar.xml"/> + <exclude name="**/weblogic*.xml"/> + </ejbjar> +</pre> + +<p>This example shows ejbjar being used to generate deployment jars for a TOPLink-enabled entity bean using a +Weblogic EJB container. This example does not require the deployment descriptors to use the naming standard. +This will create only one TOPLink-enabled ejb jar file - 'Address.jar'.</p> + +<pre> + <ejbjar srcdir="${build.dir}" + destdir="${solant.ejb.dir}" + descriptordir="${descriptor.dir}" + basejarname="Address"> + <weblogictoplink destdir="${solant.ejb.dir}" + classpath="${java.class.path}" + keepgeneric="false" + toplinkdescriptor="Address.xml" + toplinkdtd="file:///dtdfiles/toplink-cmp_2_5_1.dtd" + suffix=".jar"/> + <include name="**/ejb-jar.xml"/> + <exclude name="**/weblogic-ejb-jar.xml"/> + </ejbjar> +</pre> + +<p>This final example shows how you would set-up ejbjar under Weblogic 6.0. It also shows the use of the +<code><support></code> element to add support files</p> + +<pre> + <ejbjar descriptordir="${dd.dir}" srcdir="${build.classes.server}"> + <include name="**/*-ejb-jar.xml"/> + <exclude name="**/*-weblogic-ejb-jar.xml"/> + <support dir="${build.classes.server}"> + <include name="**/*.class"/> + </support> + <weblogic destdir="${deployment.dir}" + keepgeneric="true" + suffix=".jar" + rebuild="false"> + <classpath> + <pathelement path="${build.classes.server}"/> + </classpath> + <wlclasspath> + <pathelement path="${weblogic.classes}"/> + </wlclasspath> + </weblogic> + </ejbjar> +</pre> + + +<h3><a name="ejbjar_websphere">WebSphere element</a></h3> + +<p>The websphere element searches for the websphere specific deployment descriptors and +adds them to the final ejb jar file. Websphere has two specific descriptors for session +beans: +<ul> + <li>ibm-ejb-jar-bnd.xmi</li> + <li>ibm-ejb-jar-ext.xmi</li> +</ul> +and another two for container managed entity beans: +<ul> + <li>Map.mapxmi</li> + <li>Schema.dbxmi</li> +</ul> +In terms of WebSphere, the generation of container code and stubs is called <code>deployment</code>. +This step can be performed by the websphere element as part of the jar generation process. If the +switch <code>ejbdeploy</code> is on, the ejbdeploy tool from the websphere toolset is called for +every ejb-jar. Unfortunately, this step only works, if you use the ibm jdk. Otherwise, the rmic +(called by ejbdeploy) throws a ClassFormatError. Be sure to switch ejbdeploy off, if run ant with +Oracle JDK or OpenJDK. +</p> + +<p> +For the websphere element to work, you have to provide a complete classpath, that contains all +classes, that are required to reflect the bean classes. For ejbdeploy to work, you must also provide +the classpath of the ejbdeploy tool and set the <i>websphere.home</i> property (look at the examples below). +</p> + +<table border="1" cellpadding="2" cellspacing="0"> + <tr> + <td valign="top"><b>Attribute</b></td> + <td valign="top"><b>Description</b></td> + <td align="center" valign="top"><b>Required</b></td> + </tr> + <tr> + <td valign="top">destdir</td> + <td valign="top">The base directory into which the generated weblogic ready + jar files are deposited. Jar files are deposited in + directories corresponding to their location within the + descriptordir namespace. </td> + <td valign="top" align="center">Yes</td> + </tr> + <tr> + <td valign="top">ejbdeploy</td> + <td valign="top">Decides whether ejbdeploy is called. When you set this to true, + be sure, to run ant with the ibm jdk.</td> + <td valign="top" align="center">No, defaults to true</td> + </tr> + <tr> + <td valign="top">suffix</td> + <td valign="top">String value appended to the basename of the deployment + descriptor to create the filename of the WebLogic EJB + jar file.</td> + <td valign="top" align="center">No, defaults to '.jar'.</td> + </tr> + <tr> + <td valign="top">keepgeneric</td> + <td valign="top">This controls whether the generic file used as input to + ejbdeploy is retained.</td> + <td valign="top" align="center">No, defaults to false</td> + </tr> + <tr> + <td valign="top">rebuild</td> + <td valign="top">This controls whether ejbdeploy is called although no changes + have occurred.</td> + <td valign="top" align="center">No, defaults to false</td> + </tr> + <tr> + <td valign="top">tempdir</td> + <td valign="top">A directory, where ejbdeploy will write temporary files</td> + <td valign="top" align="center">No, defaults to '_ejbdeploy_temp'.</td> + </tr> + <tr> + <td valign="top">dbName<br>dbSchema</td> + <td valign="top">These options are passed to ejbdeploy.</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">dbVendor</td> + <td valign="top">This option is passed to ejbdeploy. + <p> + Valid options can be obtained by running the following command: + <code> + <WAS_HOME>/bin/EJBDeploy.[sh/bat] -help + </code> + </p> + This is also used to determine the name of the Map.mapxmi and + Schema.dbxmi files, for example Account-DB2UDBWIN_V71-Map.mapxmi + and Account-DB2UDBWIN_V71-Schema.dbxmi. + </td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">codegen<br>quiet<br>novalidate<br>noinform<br>trace<br> + use35MappingRules</td> + <td valign="top">These options are all passed to ejbdeploy. All options + except 'quiet' default to false.</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="top">rmicOptions</td> + <td valign="top">This option is passed to ejbdeploy and will be passed + on to rmic.</td> + <td valign="top" align="center">No</td> + </tr> +</table> + +<p>This example shows ejbjar being used to generate deployment jars for all deployment descriptors +in the descriptor dir:</p> + +<pre> + <property name="websphere.home" value="${was4.home}"/> + <ejbjar srcdir="${build.class}" descriptordir="etc/ejb"> + <include name="*-ejb-jar.xml"/> + <websphere dbvendor="DB2UDBOS390_V6" + ejbdeploy="true" + oldCMP="false" + tempdir="/tmp" + destdir="${dist.server}"> + <wasclasspath> + <pathelement location="${was4.home}/deploytool/itp/plugins/org.eclipse.core.boot/boot.jar"/> + <pathelement location="${was4.home}/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime/batch.jar"/> + <pathelement location="${was4.home}/lib/xerces.jar"/> + <pathelement location="${was4.home}/lib/ivjejb35.jar"/> + <pathelement location="${was4.home}/lib/j2ee.jar"/> + <pathelement location="${was4.home}/lib/vaprt.jar"/> + </wasclasspath> + <classpath> + <path refid="build.classpath"/> + </classpath> + </websphere> + <dtd publicId="-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN" + location="${lib}/dtd/ejb-jar_1_1.dtd"/> + </ejbjar> +</pre> + +<h3><a name="ejbjar_iplanet">iPlanet Application Server (iAS) element</a></h3> + +The <iplanet< nested element is used to build iAS-specific stubs and + +skeletons and construct a JAR file which may be deployed to the iPlanet +Application Server 6.0. The build process will always determine if +the EJB stubs/skeletons and the EJB-JAR file are up to date, and it will +do the minimum amount of work required. +<p>Like the WebLogic element, a naming convention for the EJB descriptors +is most commonly used to specify the name for the completed JAR file. +For example, if the EJB descriptor ejb/Account-ejb-jar.xml is found in +the descriptor directory, the iplanet element will search for an iAS-specific +EJB descriptor file named ejb/Account-ias-ejb-jar.xml (if it isn't found, +the task will fail) and a JAR file named ejb/Account.jar will be written +in the destination directory. Note that when the EJB descriptors +are added to the JAR file, they are automatically renamed META-INF/ejb-jar.xml +and META-INF/ias-ejb-jar.xml.</p> +<p>Of course, this naming behaviour can be modified by specifying attributes +in the ejbjar task (for example, basejarname, basenameterminator, and flatdestdir) +as well as the iplanet element (for example, suffix). Refer to the +appropriate documentation for more details.</p> +<h3> +Parameters:</h3> + +<table border="1" cellpadding="2" cellspacing="0"> +<tr> +<td valign="top"><b>Attribute</b></td> + +<td valign="top"><b>Description</b></td> + +<td align="center" valign="top"><b>Required</b></td> +</tr> + +<tr> +<td valign="top">destdir</td> + +<td valign="top">The base directory into which the generated JAR files will +be written. Each JAR file is written in directories which correspond to +their location within the "descriptordir" namespace.</td> + +<td align="center" valign="top">Yes</td> +</tr> + +<tr> +<td valign="top">classpath</td> + +<td valign="top">The classpath used when generating EJB stubs and skeletons. +If omitted, the classpath specified in the "ejbjar" parent task will be +used. If specified, the classpath elements will be prepended to the +classpath specified in the parent "ejbjar" task. Note that nested "classpath" +elements may also be used.</td> + +<td align="center" valign="top">No</td> +</tr> + +<tr> +<td valign="top">keepgenerated</td> + +<td valign="top">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. If omitted, it defaults to "no". </td> + +<td align="center" valign="top">No</td> +</tr> + +<tr> +<td valign="top">debug</td> + +<td>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. If omitted, it defaults to "no". </td> + +<td align="center" valign="top">No</td> +</tr> + +<tr> +<td valign="top">iashome</td> + +<td>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. If omitted, the ejbc utility must be on the user's system +path. </td> + +<td align="center" valign="top">No</td> +</tr> + +<tr> +<td valign="top">suffix</td> + +<td>String value appended to the JAR filename when creating each JAR. +If omitted, it defaults to ".jar". </td> + +<td align="center" valign="top">No</td> +</tr> +</table> + +<p>As noted above, the iplanet element supports additional <code><classpath></code> +nested elements.</p> +<h3> +Examples</h3> +This example demonstrates the typical use of the <code><iplanet></code> nested element. +It will name each EJB-JAR using the "basename" prepended to each standard +EJB descriptor. For example, if the descriptor named "Account-ejb-jar.xml" +is processed, the EJB-JAR will be named "Account.jar" +<pre> + <ejbjar srcdir="${build.classesdir}" + descriptordir="${src}"> + + <iplanet destdir="${assemble.ejbjar}" + classpath="${ias.ejbc.cpath}"/> + <include name="**/*-ejb-jar.xml"/> + <exclude name="**/*ias-*.xml"/> + </ejbjar></pre> + +This example demonstrates the use of a nested classpath element as well +as some of the other optional attributes. +<pre> + <ejbjar srcdir="${build.classesdir}" + descriptordir="${src}"> + + <iplanet destdir="${assemble.ejbjar}" + iashome="${ias.home}" + debug="yes" + keepgenerated="yes"> + <classpath> + <pathelement path="."/> + <pathelement path="${build.classpath}"/> + </classpath> + </iplanet> + <include name="**/*-ejb-jar.xml"/> + <exclude name="**/*ias-*.xml"/> + </ejbjar></pre> + +This example demonstrates the use of basejarname attribute. In this +case, the completed EJB-JAR will be named "HelloWorld.jar" If multiple +EJB descriptors might be found, care must be taken to ensure that the completed +JAR files don't overwrite each other. +<pre> + <ejbjar srcdir="${build.classesdir}" + descriptordir="${src}" + basejarname="HelloWorld"> + + <iplanet destdir="${assemble.ejbjar}" + classpath="${ias.ejbc.cpath}"/> + <include name="**/*-ejb-jar.xml"/> + <exclude name="**/*ias-*.xml"/> + </ejbjar></pre> +This example demonstrates the use of the dtd nested element. If the local +copies of the DTDs are included in the classpath, they will be automatically +referenced without the nested elements. In iAS 6.0 SP2, these local DTDs are +found in the [iAS-install-directory]/APPS directory. In iAS 6.0 SP3, these +local DTDs are found in the [iAS-install-directory]/dtd directory. +<pre> + <ejbjar srcdir="${build.classesdir}" + descriptordir="${src}"> + <iplanet destdir="${assemble.ejbjar}"> + classpath="${ias.ejbc.cpath}"/> + <include name="**/*-ejb-jar.xml"/> + <exclude name="**/*ias-*.xml"/> + + <dtd publicId="-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN" + location="${ias.home}/APPS/ejb-jar_1_1.dtd"/> + <dtd publicId="-//Sun Microsystems, Inc.//DTD iAS Enterprise JavaBeans 1.0//EN" + location="${ias.home}/APPS/IASEjb_jar_1_0.dtd"/> + </ejbjar></pre> + +<h3><a name="ejbjar_jonas">JOnAS (Java Open Application Server) element</a></h3> + +<p>The <code><jonas></code> nested element is used to build JOnAS-specific stubs and +skeletons thanks to the <code>GenIC</code> specific tool, and construct a JAR +file which may be deployed to the JOnAS Application Server. The build process +will always determine if the EJB stubs/skeletons and the EJB-JAR file are up to +date, and it will do the minimum amount of work required.</p> + +<p>Like the WebLogic element, a naming convention for the EJB descriptors is +most commonly used to specify the name for the completed JAR file. For example, +if the EJB descriptor <code>ejb/Account-ejb-jar.xml</code> is found in the +descriptor directory, the <code><jonas></code> element will search for a JOnAS-specific +EJB descriptor file named <code>ejb/Account-jonas-ejb-jar.xml</code> and a JAR +file named <code>ejb/Account.jar</code> will be written in the destination +directory. But the <code><jonas></code> element can also use the JOnAS naming +convention. With the same example as below, the EJB descriptor can also be named +<code>ejb/Account.xml</code> (no base name terminator here) in the descriptor +directory. Then the <code><jonas></code> element will search for a JOnAS-specific EJB +descriptor file called <code>ejb/jonas-Account.xml</code>. This convention do +not follow strictly the ejb-jar naming convention recommendation but is +supported for backward compatibility with previous version of JOnAS.</p> + +<p>Note that when the EJB descriptors are added to the JAR file, they are +automatically renamed <code>META-INF/ejb-jar.xml</code> and +<code>META-INF/jonas-ejb-jar.xml</code>.</p> + +<p>Of course, this naming behavior can be modified by specifying attributes in +the ejbjar task (for example, basejarname, basenameterminator, and flatdestdir) +as well as the iplanet element (for example, suffix). Refer to the appropriate +documentation for more details.</p> + +<h3> Parameters:</h3> + +<table border="1" cellspacing="0" cellpadding="2"> + <tbody> + <tr> + <td valign="Top"><b>Attribute</b></td> + <td valign="Top"><b>Description</b></td> + <td align="Center" valign="Top"><b>Required</b></td> + </tr> + <tr> + <td valign="Top">destdir</td> + <td valign="Top">The base directory into which the generated JAR files + will be written. Each JAR file is written in directories which correspond + to their location within the "<code>descriptordir</code>" namespace.</td> + <td align="Center" valign="Top">Yes</td> + </tr> + <tr> + <td valign="Top">jonasroot</td> + <td valign="Top">The root directory for JOnAS.</td> + <td valign="Top" align="Center">Yes</td> + </tr> + <tr> + <td valign="Top">classpath</td> + <td valign="Top">The classpath used when generating EJB stubs and + skeletons. If omitted, the classpath specified in the "ejbjar" parent + task will be used. If specified, the classpath elements will be prepended + to the classpath specified in the parent "ejbjar" task (see also the ORB + attribute documentation below). Note that nested "classpath" elements may + also be used.</td> + <td valign="Top" align="Center">No</td> + </tr> + <tr> + <td valign="Top">keepgenerated</td> + <td valign="Top"><code>true</code> if the intermediate Java + source files generated by GenIC must be deleted or not. If + omitted, it defaults to <code>false</code>.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">nocompil</td> + <td valign="Top"><code>true</code> if the generated source files + must not be compiled via the java and rmi compilers. If omitted, + it defaults to <code>false</code>.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">novalidation</td> + <td valign="Top"><code>true</code> if the XML deployment descriptors must + be parsed without validation. If omitted, it defaults to <code>false</code>.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">javac</td> + <td valign="Top">Java compiler to use. If omitted, it defaults + to the value of <code>build.compiler</code> property.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">javacopts</td> + <td valign="Top">Options to pass to the java compiler.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">rmicopts</td> + <td valign="Top">Options to pass to the rmi compiler.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="top">secpropag</td> + <td valign="top"><code>true</code> if the RMI Skel. and + Stub. must be modified to implement the implicit propagation of + the security context (the transactional context is always + provided). If omitted, it defaults to <code>false</code>.</td> + <td valign="top" align="center">No</td> + </tr> + <tr> + <td valign="Top">verbose</td> + <td valign="Top">Indicates whether or not to use -verbose switch. If + omitted, it defaults to <code>false</code>.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">additionalargs</td> + <td valign="Top">Add additional args to GenIC.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">keepgeneric</td> + <td valign="Top"><code>true</code> if the generic JAR file used as input + to GenIC must be retained. If omitted, it defaults to <code>false</code>.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">jarsuffix</td> + <td>String value appended to the JAR filename when creating each JAR. If + omitted, it defaults to ".jar". </td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">orb</td> + <td>Choose your ORB : RMI, JEREMIE, DAVID. If omitted, it defaults to the + one present in classpath. If specified, the corresponding JOnAS JAR is + automatically added to the classpath.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + <td valign="Top">nogenic</td> + <td valign="Top">If this attribute is set to <code>true</code>, + JOnAS's GenIC will not be run on the EJB JAR. Use this if you + prefer to run GenIC at deployment time. If omitted, it defaults + to <code>false</code>.</td> + <td align="Center" valign="Top">No</td> + </tr> + <tr> + </tbody> +</table> + +<p>As noted above, the jonas element supports additional <code><classpath></code> +nested elements.</p> + +<h3>Examples</h3> + +<p>This example shows ejbjar being used to generate deployment jars using a +JOnAS EJB container. This example requires the naming standard to be used for +the deployment descriptors. Using this format will create a EJB JAR file for +each variation of '*-jar.xml' that is found in the deployment descriptor +directory. </p> + +<pre> + <ejbjar srcdir="${build.classes}" + descriptordir="${descriptor.dir}"> + <jonas destdir="${deploymentjars.dir}" + jonasroot="${jonas.root}" + orb="RMI"/> + <include name="**/*.xml"/> + <exclude name="**/jonas-*.xml"/> + <support dir="${build.classes}"> + <include name="**/*.class"/> + </support> + </ejbjar> +</pre> + +<p>This example shows ejbjar being used to generate a single deployment jar +using a JOnAS EJB container. This example does require the deployment +descriptors to use the naming standard. This will create only one ejb jar file - +'TheEJBJar.jar'.</p> + +<pre> + <ejbjar srcdir="${build.classes}" + descriptordir="${descriptor.dir}" + basejarname="TheEJBJar"> + <jonas destdir="${deploymentjars.dir}" + jonasroot="${jonas.root}" + suffix=".jar" + classpath="${descriptorbuild.classpath}"/> + <include name="**/ejb-jar.xml"/> + <exclude name="**/jonas-ejb-jar.xml"/> + </ejbjar> +</pre> + + + + +</body> + +</html> |