web server - Borland Technical Publications

web server - Borland Technical Publications web server - Borland Technical Publications

techpubs.borland.com
from techpubs.borland.com More from this publisher
12.11.2014 Views

Using the iastool command-line tools The following example displays detailed information on the compress tool: iastool -usage compress The following example displays detailed information on the -start, -stop, and -restart tools: iastool -usage start stop restart verify Use this tool to check an archive file for correctness and consistency, and to check if all of the elements required for deploying your application are in place. The verification process supports the following roles that correspond to a phase in the application's life cycle and the appropriate level of verification (similar to the J2EE role definitions): ■ ■ Developer: This is the lowest verification level. All xml is checked for syntax as well as standard and proprietary keywords relevant to the current archive type. Consistency across the archive is checked, but no external resources are verified at this level. Assembler: Once the archives are individually verified and are correct, other resources built into an application will start to be verified. For example, this level will verify the existence and correctness of URIs (Uniform Resource Identifiers), but not EJB or JNDI links. ■ Deployer: (the default) All checks are turned on. EJB and JNDI links are checked at this level as well as the operational environment in which the application is to be deployed. Supported archive types are EAR, EJB, WAR, JNDI, and Client JARs. The typical archive verification process includes the following checks: ■ A pass over the XML, checking for correct XML syntax. ■ Verification of the semantics of the standard and proprietary XML descriptors, and the compliance with their required descriptors for each supported archive type. Verification always occurs in a hierarchical fashion, starting with the top module, then recursively working through its submodules, and finally checking for inter-archive links. Syntax -verify -src [-role ] [-nowarn] [-strict] [-classpath ] Default Output By default, verify reports nothing (for example, if no errors are found in the specified module). Chapter 29: iastool command-line utility 321

Executing iastool command-line tools from a script file Options The following table describes the options available when using the verify tool. Option -src -role -nowarn -strict -classpath Description Specifies the JAR file (or the directory of an expanded JAR) that you want to verify. The full or relative path to the file must be specified. There is no default. Specifies the level of error checking to perform: ■ ■ DEVELOPER ASSEMBLER ■ DEPLOYER (default) For details, see the role descriptions above. Specifies that the tool should only report errors that preclude deployment and not report warnings. Specifies that the tool should report the most minute inconsistencies, many of which do not affect the overall integrity of the application. Specifies the search path for application classes and resources. To enter more than one directory, ZIP, or JAR file entry, separate each entry with a semicolon (;). Example The following example performs a developer level verification of the JAR file soapclient.jar located in the c:\examples\soap directory: -verify -src c:\examples\soap\soap-client.jar -role DEVELOPER Executing iastool command-line tools from a script file Several iastool utility tools require that you supply login information (realm, username, and password). You may, however, want to run iastool commands from a script file, but doing so would expose the realm, username, password information to anyone who has access to the script file. There are two methods you can use to protect this information: ■ “Piping a file to the iastool utility” on page 321 ■ “Passing a file to the iastool utility” on page 322 Piping a file to the iastool utility The following example shows how to ping a hub named east1 by piping the file mylogin.txt (located in the default Borland Deployment Platform installation directory) to the iastool utility: iastool -ping -hub east1 < c:\BES\mylogin.txt where the file mylogin.txt contains three lines that correspond to what you would enter for the realm, username, and password: 2 username password 322 BES Developer’s Guide

Using the iastool command-line tools<br />

The following example displays detailed information on the compress tool:<br />

iastool -usage compress<br />

The following example displays detailed information on the -start, -stop, and -restart<br />

tools:<br />

iastool -usage start stop restart<br />

verify<br />

Use this tool to check an archive file for correctness and consistency, and to check if all<br />

of the elements required for deploying your application are in place.<br />

The verification process supports the following roles that correspond to a phase in the<br />

application's life cycle and the appropriate level of verification (similar to the J2EE role<br />

definitions):<br />

■<br />

■<br />

Developer: This is the lowest verification level. All xml is checked for syntax as well<br />

as standard and proprietary keywords relevant to the current archive type.<br />

Consistency across the archive is checked, but no external resources are verified at<br />

this level.<br />

Assembler: Once the archives are individually verified and are correct, other<br />

resources built into an application will start to be verified. For example, this level will<br />

verify the existence and correctness of URIs (Uniform Resource Identifiers), but not<br />

EJB or JNDI links.<br />

■<br />

Deployer: (the default) All checks are turned on. EJB and JNDI links are checked at<br />

this level as well as the operational environment in which the application is to be<br />

deployed.<br />

Supported archive types are EAR, EJB, WAR, JNDI, and Client JARs. The typical<br />

archive verification process includes the following checks:<br />

■<br />

A pass over the XML, checking for correct XML syntax.<br />

■<br />

Verification of the semantics of the standard and proprietary XML descriptors, and<br />

the compliance with their required descriptors for each supported archive type.<br />

Verification always occurs in a hierarchical fashion, starting with the top module, then<br />

recursively working through its submodules, and finally checking for inter-archive links.<br />

Syntax<br />

-verify -src [-role ] [-nowarn]<br />

[-strict] [-classpath ]<br />

Default Output<br />

By default, verify reports nothing (for example, if no errors are found in the specified<br />

module).<br />

Chapter 29: iastool command-line utility 321

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!