Sun GlassFish Enterprise Server v2.1.1 Application Deployment Guide

Assembling Modules and Applications

Assembling (or packaging) modules and applications in Enterprise Server conforms to all of the customary Java-EE-defined specifications. The only difference is that when you assemble in Enterprise Server, you can include optional Enterprise Server specific deployment descriptors that enhance the functionality of the Enterprise Server. You can also package the Enterprise Server specific deployment descriptors separately in a deployment plan; see Using a Deployment Plan.

For example, when you assemble an EJB JAR module, you annotate or create two deployment descriptor files with these names: ejb-jar.xml and sun-ejb-jar.xml. If the EJB component is an entity bean with container-managed persistence, you can also create a .dbschema file and a sun-cmp-mapping.xml file. For more information about sun-ejb-jar.xml and sun-cmp-mapping.xml, see Appendix A, Deployment Descriptor Files.

Note –

According to the Java EE specification, section, “Dependencies,” you cannot package utility classes within an individually deployed EJB module. Instead, package the EJB module and utility JAR within an application using the JAR Extension Mechanism Architecture. For other alternatives, see Chapter 2, Class Loaders, in Sun GlassFish Enterprise Server v2.1.1 Developer’s Guide.

The Enterprise Server provides these tools for assembling and verifying a module or an application:

The asant Utility

The asant utility can help you assemble and deploy modules and applications. For details, see Chapter 3, The asant Utility, in Sun GlassFish Enterprise Server v2.1.1 Developer’s Guide.

The NetBeans IDE

You can use the NetBeansTM Integrated Development Environment (IDE) to assemble Java EE applications and modules. The GlassFish edition of the Enterprise Server is bundled with the NetBeans 5.5 IDE. For more information about using the NetBeans IDE, see

The verifier Utility

The verifier utility validates Java EE annotations and deployment descriptors and Enterprise Server specific deployment descriptors against their corresponding DTD or schema files. It gives errors and warnings if a module or application is not Java EE and Enterprise Server compliant. You can verify deployment descriptors in EAR, WAR, RAR, and JAR files.

The verifier tool is not simply an XML syntax verifier. Rules and interdependencies between various elements in the deployment descriptors are verified. Where needed, user application classes are introspected to apply validation rules.

The verifier is integrated into Enterprise Server deployment and the asant task The sun-appserv-deploy Task in Sun GlassFish Enterprise Server v2.1.1 Developer’s Guide. You can also run it as a stand-alone utility from the command line. The verifier utility is located in the as-install/bin directory.

You can run the verifier during Enterprise Server deployment using the Admin Console or the asadmin deploy command with the --verify="true" option (see The asadmin Deployment Commands and The Admin Console Deployment Pages). In these cases, the output of the verifier is written to the tempdir/verifier-results/ directory, where tempdir is the temporary directory defined in the operating system. Deployment fails if any failures are reported during the verification process. The verifier also logs information about verification progress to the standard output.

For details on all the assertions tested by the verifier, see the assertions documentation provided at

Tip –

Using the verifier tool can help you avoid runtime errors that are difficult to debug.

This section covers the following topics:

Command-Line Syntax

The verifier tool’s syntax is as follows:

verifier [options] file

The file can be an EAR, WAR, RAR, or JAR file.

The following table shows the options for the verifier tool.

Table 1–1 Verifier Options

Short Form 

Long Form 




Turns on verbose mode. In verbose mode, the status of each run of each test is displayed on the verifier console. 

-d output-dir

--destdir output-dir

Writes test results to the output-dir, which must already exist. By default, the results files are created in the current directory.

-D domain-dir

--domain domain-dir

Specifies the absolute path to the domain directory. This option is ignored if the -p option is used. The default domain directory isas-install/domains/domain1.


--reportlevel level

Sets the output report level to one of the following values:

  • a or all - Reports all results.

  • w or warnings - Reports only warning and failure results. This is the default.

  • f or failures - Reports only failure results.



Appends a timestamp to the output file name. The format of the timestamp is yyyyMMddhhmmss. 



Displays help for the verifier command. If you use this option, you do not need to specify an EAR, WAR, RAR, or JAR file.



Displays the verifier tool version. If you use this option, you do not need to specify an EAR, WAR, RAR, or JAR file.



Verifies portable features only. By default, the verifier also checks correct usage of Enterprise Server features in the sun-*.xml deployment descriptor files.



Runs only the application tests. 



Runs only the application client tests. 



Runs only the connector tests. 



Runs only the EJB tests. 



Runs only the web module tests.  



Runs only the web service tests. 



Runs only the web service client tests. 

For example, the following command runs the verifier on the ejb.jar file with default settings:

verifier ejb.jar

The results files are ejb.jar.txt and ejb.jar.xml.

For a more complex example, the following command runs the verifier on the ejb.jar file in portability mode displaying only failures and with a timestamp:

verifier -p -rf -t ejb.jar

The results files are ejb.jartimestamp.txt and ejb.jartimestamp.xml. The format of the timestamp is yyyyMMddhhmmss.

If the verifier runs successfully and no verification errors occurred, a result code of 0 is returned. A nonzero error code is returned if errors occurred or the verifier fails to run.

Ant Integration

You can integrate the verifier into an Ant build file as a target and use the Ant call feature to call the target each time an application or module is assembled. You can use any of the arguments described in Table 1–1. Example code for an Ant verify target is as follows:

<?xml version="1.0" encoding="iso-8859-1"?>
<project name="Verifier Launcher" default="verify">
    <target name="verify" description="verify using verifier script">
        <exec executable="as-install/bin/verifier" 
                failonerror="true" vmlauncher="false">
            <arg line="-d /tmp path-to-app"/>

Sample Results Files

Here is a sample results XML file:

Session bean with bean managed transaction demarcation test
For [ TheGreeter ] Error: Session Beans [ TheGreeter ] with 
[ Bean ] managed transaction demarcation should not have 
container transactions defined.

Here is a sample results TXT file:


# of Failures : 1
# of Warnings : 0
# of Errors : 0



Test Name : tests.ejb.ejb30.BusinessIntfInheritance
Test Assertion : A business interface must not extend javax.ejb.EJBObject 
or javax.ejb.EJBLocalObject. Please refer to EJB 3.0 Simplified API Section 
#3.2 for further information.
Test Description : For [ sessionApp#session-ejb.jar#HelloEJB ]
[ com.sun.sample.session.Hello ] extends either javax.ejb.EJBObject or