web server - Borland Technical Publications
web server - Borland Technical Publications web server - Borland Technical Publications
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
- Page 281 and 282: Deploying the Resource Adapter Pack
- Page 283 and 284: Application development overview 8
- Page 285 and 286: Application development overview //
- Page 287 and 288: Application development overview
- Page 289 and 290: Other Considerations Other Consider
- Page 291 and 292: Other Considerations To illustrate,
- Page 293 and 294: Other Considerations } } { cf = new
- Page 295 and 296: General syntax and usage General sy
- Page 297 and 298: Syntax and usage for iastool Table
- Page 299 and 300: Syntax and usage for java2iiop Exam
- Page 301 and 302: Syntax and usage for appclient Tabl
- Page 303 and 304: Building and running the BES exampl
- Page 305 and 306: Using the iastool command-line tool
- Page 307 and 308: Using the iastool command-line tool
- Page 309 and 310: Using the iastool command-line tool
- Page 311 and 312: Using the iastool command-line tool
- Page 313 and 314: Using the iastool command-line tool
- Page 315 and 316: Using the iastool command-line tool
- Page 317 and 318: Using the iastool command-line tool
- Page 319 and 320: Using the iastool command-line tool
- Page 321 and 322: Using the iastool command-line tool
- Page 323 and 324: Using the iastool command-line tool
- Page 325 and 326: Using the iastool command-line tool
- Page 327 and 328: Using the iastool command-line tool
- Page 329 and 330: Using the iastool command-line tool
- Page 331: Using the iastool command-line tool
- Page 335 and 336: 324 BES Developer’s Guide
- Page 337 and 338: element ■ ■ ■ element The
- Page 339 and 340: element The Partition statistics ag
- Page 341 and 342: element element The services eleme
- Page 343 and 344: element element The archive elemen
- Page 345 and 346: EJB Container-level Properties Tabl
- Page 347 and 348: EJB Container-level Properties Tabl
- Page 349 and 350: EJB Customization Properties: Deplo
- Page 351 and 352: Complete Index of EJB Properties Co
- Page 353 and 354: Complete Index of EJB Properties Ta
- Page 355 and 356: Complete Index of EJB Properties Ta
- Page 357 and 358: Complete Index of EJB Properties Ta
- Page 359 and 360: Java Session Service (JSS) Properti
- Page 361 and 362: Java Session Service (JSS) Properti
- Page 363 and 364: Partition Transaction Service (Tran
- Page 365 and 366: Borland-specific web DTD 33, 36 bra
- Page 367 and 368: ejb.mdb.maxMessagesPerServerSession
- Page 369 and 370: J J2EE VisiClient 97 VisiClient env
- Page 371 and 372: optimistic concurrency 130 SelectFo
- Page 373 and 374: Sonic clustered service 228 SonicMQ
- Page 375: X XML DTD 99 VisiClient 98 grammar
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