From b9421dc80af485591a9c50cc8921f912e0def11e Mon Sep 17 00:00:00 2001
From: Ashlee Young 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:Apache Ant EJB Tasks User Manual
-
-
-
-
-Table of Contents
-
-
-
-
-Introduction
-
-
-
-
- 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.
-
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 |
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> -- -
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. -If omitted, the classpath specified when Ant was started will be used. -Nested "classpath" elements may also be used. | - -No | -
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. If omitted, it defaults to "no". | - -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. If omitted, it 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. If omitted, the ejbc utility must be on the user's system path. | - -No | -
-<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 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.
Attribute | -Description | -Required for 4.5.1 and 5.1 | -Required for 6.0 | -
BEA Home | -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 | -N/A | -Yes | -
home | -The location of the weblogic home that is to be used. This is the location - where weblogic is installed. | -Yes | -Yes. Note this is the absolute location, not relative to - BEA home. | -
Domain | -The domain to which the server belongs. | -N/A | -Yes | -
classpath | -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 | -Yes | -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 | -N/A | -
name | -The name of the weblogic server within the weblogic home which is to be run. - This defaults to "myserver" | -No | -No | -
policy | -The name of the security policy file within the weblogic home directory that
- is to be used. If not specified, the default policy file weblogic.policy
- is used. |
- No | -No | -
username | -The management username used to manage the server | -N/A | -No | -
password | -The server's management password | -N/A | -Yes | -
pkPassword | -The private key password so the server can decrypt the SSL - private key file | -N/A | -No | -
jvmargs | -Additional argument string passed to the Java Virtual Machine used to run the - Weblogic instance. | -No | -No | -
weblogicMainClass | -name of the main class for weblogic | -No | -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 version of Weblogic, including 6.0. You need to -specify the BEA Home 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 Java Virtual Machine 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. This defaults to an - immediate shutdown. | -No | -
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:
-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 <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 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.
- - -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. - -
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. -
-
-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
-/home/user/dev/appserver/dd/sample
, then the generated
-bean will be named sample.jar
-
-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. -
- -
-The final scheme supported by the <ejbjar>
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.
-
-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. -
- - - -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.
- -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. -
- -The ejbjar task in Ant releases 1.5 and later uses the - BCEL 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. -
- -In Ant 1.5, a new attribute, dependency
has been introduced to allow the
-buildfile to control what additional classes are added to the generated jar. It takes three
-possible values
none
- only the bean classes and interfaces described in the bean's
-descriptor are added to the jar.super
- this is the default value and replicates the original ejbjar
-behaviour where super classes and super interfaces are added to the jarfull
- In this mode all classes used by the bean's classes and interfaces
-are added to the jarThe super
and full
values require the
- BCEL library
-to be available. If it is not, ejbjar will drop back to the behaviour corresponding to
-the value none
.
Attribute | -Description | -Required | -
descriptordir | -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. | -No | -
srcdir | -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. | -Yes | -
destdir | -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). | -Yes, unless vendor-specific deployment elements - have been specified. | -
cmpversion | -Either 1.0 or 2.0 .- Default is 1.0 .- A CMP 2.0 implementation exists currently only for JBoss. |
- No | -
naming | -Controls the naming convention used to name generated - EJB jars. Please refer to the description above. | -No | -
basejarname | -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). | -No | -
basenameterminator | -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. | -No, defaults to '-'. | -
genericjarsuffix | -String value appended to the basename of the deployment - descriptor to create the filename of the generic EJB jar - file. | -No, defaults to '-generic.jar'. | -
classpath | -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 | -No. | -
flatdestdir | -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. | -No. | -
dependency | -This attribute controls which additional classes and interfaces - are added to the jar. Please refer to the description - above | -No. | -
manifest | -the manifest file to use, if any. | -No | -
In addition to the vendor specific nested elements, the ejbjar task provides -three nested elements.
- -The <classpath>
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.
The <dtd>
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 <dtd>
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
-<dtd>
element.
Attribute | -Description | -Required | -
publicId | -The public Id of the DTD for which the location is being provided | -Yes | -
location | -The location of the local copy of the DTD. This can either be a - file or a resource loadable from the classpath. | -Yes | -
The <support>
nested element is used to supply additional classes
-(files) to be included in the generated jars. The <support>
element is a
-FileSet, so it can either reference a fileset declared elsewhere or it can be
-defined in-place with the appropriate <include>
and <exclude>
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.
The jboss element searches for the JBoss specific deployment descriptors and adds them -to the final ejb jar file. JBoss has two deployment descriptors: -
CMP version | File name |
CMP 1.0 | jaws.xml |
CMP 2.0 | jbosscmp-jdbc.xml |
Attribute | -Description | -Required | -
destdir | -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. | -Yes | -
genericjarsuffix | -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. | -No, defaults to '-generic.jar'. | -
suffix | -String value appended to the basename of the deployment - descriptor to create the filename of the JBoss EJB - jar file. | -No, defaults to '.jar'. | -
keepgeneric | -This controls whether the generic file used as input to - ejbc is retained. | -No, defaults to false | -
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 <type-storage>
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.
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.
- -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 <type-storage>
element. In the above example, you would
-define this as META-INF/Customer-weblogic-cmp-rdbms-jar.xml.
Attribute | -Description | -Required | -
destdir | -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. | -Yes | -
genericjarsuffix | -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. | -No, defaults to '-generic.jar'. | -
suffix | -String value appended to the basename of the deployment - descriptor to create the filename of the WebLogic EJB - jar file. | -No, defaults to '.jar'. | -
classpath | -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 | -No | -
wlclasspath | -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 | -No | -
keepgeneric | -This controls whether the generic file used as input to - ejbc is retained. | -No, defaults to false | -
compiler | -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 build.compiler property is set
- to jikes, the Jikes compiler will be used. If this
- is not desired, the value "default "
- may be given to use the default compiler |
- No | -
rebuild | -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. - | -No, defaults to true. | -
keepgenerated | -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 - | -No, defaults to false. | -
args | -Any additional arguments to be passed to the weblogic.ejbc - tool. - | -No. | -
weblogicdtd | -Deprecated. 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 <dtd> element, described above. If you do choose
- to use an attribute, you should use a
- nested <dtd> element.
- |
- No. | -
wldtd | -Deprecated. 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 <dtd>
- element, described above.
- |
- No. | -
ejbdtd | -Deprecated. 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 <dtd> element, described above.
- |
- No. | -
newCMP | -If this is set to true, the new method for locating - CMP descriptors will be used. | -No. Defaults to false | -
oldCMP | -Deprecated This is an antonym for newCMP which should be used instead. | -No. | -
noEJBC | -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. | -No. | -
ejbcclass | -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. | -No. | -
jvmargs | -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" - | -No. | -
jvmdebuglevel | -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 - | -No. | -
outputdir | -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. - | -No. | -
The weblogic nested element supports three nested elements. The
-first two, <classpath>
and <wlclasspath>
, are used to set the
-respective classpaths. These nested elements are useful when setting up
-class paths using reference Ids. The last, <sysproperty>
, 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.
-
Deprecated
- -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" -
- -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
- -Attribute | -Description | -Required | -
toplinkdescriptor | -This specifies the name of the TOPLink deployment descriptor file contained in the - 'descriptordir' directory. | -Yes | -
toplinkdtd | -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. | -No, defaults to dtd file at www.objectpeople.com. | -
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.
- -- <ejbjar srcdir="${build.classes}" - descriptordir="${descriptor.dir}"> - <weblogic destdir="${deploymentjars.dir}" - classpath="${descriptorbuild.classpath}"/> - <include name="**/*-ejb-jar.xml"/> - <exclude name="**/*weblogic*.xml"/> - </ejbjar> -- -
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.
- -- <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> -- - -
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'.
- - -- <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> -- -
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'.
- -- <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> -- -
This final example shows how you would set-up ejbjar under Weblogic 6.0. It also shows the use of the
-<support>
element to add support files
- <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> -- - -
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: -
deployment
.
-This step can be performed by the websphere element as part of the jar generation process. If the
-switch ejbdeploy
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.
-
-
--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 websphere.home property (look at the examples below). -
- -Attribute | -Description | -Required | -
destdir | -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. | -Yes | -
ejbdeploy | -Decides whether ejbdeploy is called. When you set this to true, - be sure, to run ant with the ibm jdk. | -No, defaults to true | -
suffix | -String value appended to the basename of the deployment - descriptor to create the filename of the WebLogic EJB - jar file. | -No, defaults to '.jar'. | -
keepgeneric | -This controls whether the generic file used as input to - ejbdeploy is retained. | -No, defaults to false | -
rebuild | -This controls whether ejbdeploy is called although no changes - have occurred. | -No, defaults to false | -
tempdir | -A directory, where ejbdeploy will write temporary files | -No, defaults to '_ejbdeploy_temp'. | -
dbName dbSchema |
- These options are passed to ejbdeploy. | -No | -
dbVendor | -This option is passed to ejbdeploy.
-
- Valid options can be obtained by running the following command:
- |
- No | -
codegen quiet novalidate noinform trace - use35MappingRules |
- These options are all passed to ejbdeploy. All options - except 'quiet' default to false. | -No | -
rmicOptions | -This option is passed to ejbdeploy and will be passed - on to rmic. | -No | -
This example shows ejbjar being used to generate deployment jars for all deployment descriptors -in the descriptor dir:
- -- <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> -- -
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.
-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.
-Attribute | - -Description | - -Required | -
destdir | - -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. | - -Yes | -
classpath | - -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. | - -No | -
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. If omitted, it defaults to "no". | - -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. If omitted, it defaults to "no". | - -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. If omitted, the ejbc utility must be on the user's system -path. | - -No | -
suffix | - -String value appended to the JAR filename when creating each JAR. -If omitted, it defaults to ".jar". | - -No | -
As noted above, the iplanet element supports additional <classpath>
-nested elements.
<iplanet>
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"
-- <ejbjar srcdir="${build.classesdir}" - descriptordir="${src}"> - - <iplanet destdir="${assemble.ejbjar}" - classpath="${ias.ejbc.cpath}"/> - <include name="**/*-ejb-jar.xml"/> - <exclude name="**/*ias-*.xml"/> - </ejbjar>- -This example demonstrates the use of a nested classpath element as well -as some of the other optional attributes. -
- <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>- -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. -
- <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>-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. -
- <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>- -
The <jonas>
nested element is used to build JOnAS-specific stubs and
-skeletons thanks to the GenIC
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.
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 <jonas>
element will search for a JOnAS-specific
-EJB descriptor file named ejb/Account-jonas-ejb-jar.xml
and a JAR
-file named ejb/Account.jar
will be written in the destination
-directory. But the <jonas>
element can also use the JOnAS naming
-convention. With the same example as below, the EJB descriptor can also be named
-ejb/Account.xml
(no base name terminator here) in the descriptor
-directory. Then the <jonas>
element will search for a JOnAS-specific EJB
-descriptor file called ejb/jonas-Account.xml
. This convention do
-not follow strictly the ejb-jar naming convention recommendation but is
-supported for backward compatibility with previous version of JOnAS.
Note that when the EJB descriptors are added to the JAR file, they are
-automatically renamed META-INF/ejb-jar.xml
and
-META-INF/jonas-ejb-jar.xml
.
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.
- -Attribute | -Description | -Required | -
destdir | -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. |
- Yes | -
jonasroot | -The root directory for JOnAS. | -Yes | -
classpath | -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. | -No | -
keepgenerated | -true if the intermediate Java
- source files generated by GenIC must be deleted or not. If
- omitted, it defaults to false . |
- No | -
nocompil | -true if the generated source files
- must not be compiled via the java and rmi compilers. If omitted,
- it defaults to false . |
- No | -
novalidation | -true if the XML deployment descriptors must
- be parsed without validation. If omitted, it defaults to false . |
- No | -
javac | -Java compiler to use. If omitted, it defaults
- to the value of build.compiler property. |
- No | -
javacopts | -Options to pass to the java compiler. | -No | -
rmicopts | -Options to pass to the rmi compiler. | -No | -
secpropag | -true 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 false . |
- No | -
verbose | -Indicates whether or not to use -verbose switch. If
- omitted, it defaults to false . |
- No | -
additionalargs | -Add additional args to GenIC. | -No | -
keepgeneric | -true if the generic JAR file used as input
- to GenIC must be retained. If omitted, it defaults to false . |
- No | -
jarsuffix | -String value appended to the JAR filename when creating each JAR. If - omitted, it defaults to ".jar". | -No | -
orb | -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. | -No | -
nogenic | -If this attribute is set to true ,
- 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 false . |
- No | -
As noted above, the jonas element supports additional <classpath>
-nested elements.
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.
- -- <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> -- -
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'.
- -- <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> -- - - - - - - -- cgit 1.2.3-korg