Oracle WebLogic Server provides a number of Java utilities and Ant tasks for performing administrative and programming tasks. This chapter describes those Java utilities and Ant tasks.
To use these utilities and tasks, you must set your CLASSPATH correctly. For more information, see Modifying the Classpath.
Oracle WebLogic Server provides several Java programs that simplify installation and configuration tasks, provide services, and offer convenient shortcuts. The Java utilities provided with Oracle WebLogic Server are all described below. The command-line syntax is specified for all utilities and, for some, examples are provided.
Oracle WebLogic Server also provides a number of Ant tasks that automate common application server programming tasks. The Apache Web site provides other useful Ant tasks as well, including tasks for packaging EAR, WAR, and JAR files. For more information, see http://jakarta.apache.org/ant/manual/.
The appc compiler generates and compiles the classes needed to deploy EJBs and JSPs to Oracle WebLogic Server. It also validates the deployment descriptors for compliance with the current specifications at both the individual module level and the application level. See "appc Reference" in Programming Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
The AppletArchiver utility runs an applet in a separate frame, keeps a record of all of the downloaded classes and resources used by the applet, and packages these into either a .jar file or a .cab file. (The cabarc utility is available from Microsoft.)
$ java utils.applet.archiver.AppletArchiver URL filename
Table 2-1 describes the arguments passed to the AppletArchiver utility.
Use the autotype Ant task to generate non-built-in data type components, such as the serialization class, for Web Services. The fully qualified name for the autotype Ant task is weblogic.ant.taskdefs.webservices.javaschema.JavaSchema.
For a complete list of Web Services Ant tasks, see "Ant Task Reference" in WebLogic Web Services Reference for Oracle WebLogic Server.
Use BuildXMLGen to generate a build.xml file for enterprise applications in the split-directory structure. For complete documentation of this utility, see "Building Applications in a Split Development Directory" in Developing Applications for Oracle WebLogic Server.
The CertGen utility generates certificates that should only be used for demonstration or testing purposes, not in a production environment.
$ java utils.CertGen
-certfile <cert_file> -keyfile <private_key_file>
-keyfilepass <private_key_password>
[-cacert <ca_cert_file>][-cakey <ca_key_file>]
[-cakeypass <ca_key_password>]
[-selfsigned][-strength <key_strength>]
[-e <email_address>][-cn <common_name>]
[-ou <org_unit>][-o <organization>]
[-l <locality>][-s <state>][-c <country_code>]
[-keyusage [digitalSignature,nonRepudiation,keyEncipherment,
dataEncipherment,keyAgreement,keyCertSign,
cRLSign,encipherOnly,decipherOnly]]
[-keyusagecritical true|false]
[-subjectkeyid <subject_key_identifier>]
[-subjectkeyidformat UTF-8|BASE64]
[-help]
Table 2-2 describes the arguments that are passed to the CertGen utility.
| Argument | Definition |
|---|---|
-certfile cert_file -keyfile private_key_file |
Respectively, the output file names without extensions of the generated public certificate and private key. The appropriate extensions are appended when the |
-keyfilepass private_key_password
|
The password for the generated private key. |
-cacert ca_cert_file -cakey ca_key_file -cakeypass ca_key_password |
Respectively, the public certificate, private key file, and private key password of the CA that will be used as the issuer of the generated certificate. If one or more of these options are not specified, the relevant demonstration CA files will be used: |
-selfsigned |
Generates a self-signed certificate that can be used as a trusted CA certificate. If this argument is specified, the |
-strength key_strength
|
The length (in bits) of the keys to be generated. The longer the key, the more difficult it is for someone to break the encryption. |
-e email_address
|
The email address associated with the generated certificate. |
-cn common_name
|
The name associated with the generated certificate. |
-ou org_unit
|
The name of the organizational unit associated with the generated certificate. |
-o organization
|
The name of the organization associated with the generated certificate. |
-l locality
|
The name of a city or town. |
-s state
|
The name of the state or province in which the organizational unit (ou) operates if your organization is in the United States or Canada, respectively. Do not abbreviate. |
-c country_code
|
Two-letter ISO code for your country. The code for the United States is US. |
-keyusage [digitalSignature, nonRepudiation,keyEncipherment, dataEncipherment,keyAgreement, keyCertSign,cRLSign, encipherOnly,decipherOnly] |
Generate certificate with a keyusage extension, and with bits set according to the comma-separated list of bit names. Specify a key usage when you want to restrict the operation for a key that could be used for more than one operation. |
-keyusagecritical true|false |
By default, a keyusage extension is marked critical. To generate a certificate with a non-critical extension, use |
-subjectkeyid subject_key_identifier
|
Generates a certificate with the specified subject key identifier. |
-subjectkeyidformat UTF-8|BASE64 |
The format of the |
By default, the CertGen utility looks for the CertGenCA.der and CertGenCAKey.der files in the current directory, or in the WL_HOME directory, as specified in the weblogic.home system property or the CLASSPATH. Alternatively, you can specify CA files on the command line.
Enter the following command to generate certificate files named testcert with private key files named testkey:
$ java utils.CertGen -keyfilepass mykeypass -certfile testcert -keyfile testkey Generating a certificate with common name return and key strength 1024 issued by CA with certificate from CertGenCA.der file and key from CertGenCAKey.der file
You use weblogic.ClientDeployer to extract the client-side JAR file from a Java EE EAR file, creating a deployable JAR file. The weblogic.ClientDeployer class is executed on the Java command line with the following syntax:
java weblogic.ClientDeployer ear-file client
The ear-file argument is an expanded directory (or Java archive file with a .ear extension) that contains one or more client application JAR files.
For example:
java weblogic.ClientDeployer app.ear myclient
In the preceding example, app.ear is the EAR file that contains a Java EE client packaged in myclient.jar.
Once the client-side JAR file is extracted from the EAR file, use the weblogic.j2eeclient.Main utility to bootstrap the client-side application and point it to a WebLogic Server instance as follows:
java weblogic.j2eeclient.Main clientjar URL [application args]
For example:
java weblogic.j2eeclient.Main helloWorld.jar t3://localhost:7001 Greetings
Use clientgen to generate the client-side artifacts, such as the JAX-RPC stubs, needed to invoke a Web Service. See "Ant Task Reference" in WebLogic Web Services Reference for Oracle WebLogic Server.
WebLogic Server 9.0 does not support conversion or upgrading from a pre-6.0 version of Oracle WebLogic Server. To upgrade from version 6.1 or later, see Upgrade Guide for Oracle WebLogic Server.
The dbping command-line utility tests the connection between a DBMS and your client machine via a JDBC driver. You must complete the installation of the driver before attempting to use this utility. For more information on how to install a driver, see the documentation from your driver vendor. Also see "Using Third-Party Drivers with WebLogic Server" in Programming JDBC for Oracle WebLogic Server.
With the WebLogic Type 4 JDBC Driver for DB2, you can also use the dbping utility to create a package on the DB2 server. When you ping the database with the dbping utility, the driver automatically creates the default package on the database server if it does not already exist. If the default package already exists on the database server, the dbping utility uses the existing package.
The default DB2 package includes 200 dynamic sections. You can specify a different number of dynamic sections to create in the DB2 package with the -d option. The -d option also sets CreateDefaultPackage=true and ReplacePackage=true on the connection used in the connection test, which forces the DB2 driver to replace the DB2 package on the DB2 server. (See "Using DataDirect Documentation" in Programming JDBC for Oracle WebLogic Server for more information.) You can use the -d option with dynamic sections set at 200 to forcibly recreate a default package on the DB2 server.
Notes:
When you specify the -d option, the dbping utility recreates the default package and uses the value you specify for the number of dynamic sections. It does not modify the existing package.
To create a DB2 package, the user that you specify must have CREATE PACKAGE privileges on the database.
$ java utils.dbping DBMS [-d dynamicSections] user password DB
Table 2-3 describes the arguments that are passed to the dbping command-line utility.
| Argument | Definition |
|---|---|
DBMS
|
Varies by DBMS and JDBC driver:
|
[-d dynamicSections]
|
Specifies the number of dynamic sections to create in the DB2 package. This option is for use with the WebLogic Type 4 JDBC Driver for DB2 only. If the |
user
|
Valid database username for login. Use the same values you use with For DB2 with the |
password
|
Valid database password for the user. Use the same values you use with |
DB
|
Name and location of the database. Use the following format, depending on which JDBC driver you use:
Where:
|
The following is an example using the Oracle Thin Driver.
C:\>java utils.dbping ORACLE_THIN scott tiger dbserver1:1561:demo
**** Success!!! ****
You can connect to the database in your app using:
java.util.Properties props = new java.util.Properties();
props.put("user", "scott");
props.put("password", "tiger");
props.put("dll", "ocijdbc9");
props.put("protocol", "thin");
java.sql.Driver d =
Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
java.sql.Connection conn =
Driver.connect("jdbc:oracle:thin:@dbserver1:1561:demo", props);
The following is an example using the Derby driver. Derby is an open source relational database management system bundled with WebLogic Server for use by the sample applications and code examples as a demonstration database.
$ java utils.dbping DERBY examples examples localhost:1527/demo
**** Success!!! ****
You can connect to the database in your app using:
java.util.Properties props = new java.util.Properties();
props.put("user", "examples");
props.put("password", "examples");
java.sql.Driver d =
Class.forName("org.apache.derby.jdbc.ClientDriver").newInstance();
java.sql.Connection conn =
Driver.connect("jdbc:derby://localhost:1527/demo", props);
This Ant task calls EARInit, which generates an application.xml and a weblogic-application.xml file for an EAR. For more information, see EarInit (deprecated).
DDInit is a utility for generating deployment descriptors for applications to be deployed on Oracle WebLogic Server. Target a module's archive or folder and DDInit uses information from the module's class files to create appropriate deployment descriptor files.
In its command-line version, DDInit writes new files that overwrite existing descriptor files. If META-INF or WEB-INF does not exist, DDInit creates it.
Specify the type of Java EE deployable unit (either Web Application or Enterprise Application) for which you want deployment descriptors generated by using the DDInit command specific to the type, as described below.
Target a WAR file or a folder containing files that you intend to archive as a WAR file, and WebInit will create web.xml and weblogic.xml files for the module.
prompt> java weblogic.marathon.ddinit.WebInit <module>
The EarInit tool is deprecated in this version of Oracle WebLogic Server. As a result, you should not:
Use the DDInit utility to generate deployment descriptors for Enterprise applications.
Use the ddcreate ant task, which calls EarInit.
Generate an application.xml and a weblogic-application.xml file for an EAR using this command. Target an existing EAR or a folder containing JAR or WAR files you intend to archive into an EAR file.
prompt> java weblogic.marathon.ddinit.EarInit <module>
Using the weblogic.Deployer tool, you can deploy Java EE applications and components to WebLogic Servers in a command-line or scripting environment. For detailed information on using this tool, see "weblogic.Deployer Command-Line Reference" in Deploying Applications to Oracle WebLogic Server.
The weblogic.Deployer utility replaces the weblogic.deploy utility, which has been deprecated.
The der2pem utility converts an X509 certificate from DER format to PEM format. The .pem file is written in the same directory and has the same filename as the source .der file.
$ java utils.der2pem derFile [headerFile] [footerFile]
Table 2-4 describes the arguments that are passed to the der2pem utility.
| Argument | Description |
|---|---|
derFile
|
The name of the file to convert. The filename must end with a |
headerFile
|
The header to place in the PEM file. The default header is "-----BEGIN CERTIFICATE-----". Use a header file if the DER file being converted is a private key file, and create the header file containing one of the following:
Note: There must be a new line at the end of the header line in the file. |
footerFile
|
The header to place in the PEM file. The default header is "-----END CERTIFICATE-----". Use a footer file if the DER file being converted is a private key file, and create the footer file containing one of the following in the header:
Note: There must be a new line at the end of the header line in the file. |
Derby is an open source relational database management system based on Java, JDBC, and SQL standards. It is bundled with WebLogic Server for use by the sample applications and code examples as a demonstration database. For more information about Derby, see http://db.apache.org/derby.
See "appc Reference" in Programming Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
EJBGen is an Enterprise JavaBeans 2.0 code generator. You can annotate your Bean class file with javadoc tags and then use EJBGen to generate the Remote and Home classes and the deployment descriptor files for an EJB application, reducing to one the number of EJB files you need to edit and maintain.
See "EJBGen Reference" in Programming Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
The weblogic.security.Encrypt utility encrypts cleartext strings for use with Oracle WebLogic Server. The utility uses the encryption service of the current directory, or the encryption service for a specified Oracle WebLogic Server domain root directory.
Note:
An encrypted string must have been encrypted by the encryption service in the Oracle WebLogic Server domain where it will be used. If not, the server will not be able to decrypt the string.
You can only run the weblogic.security.Encrypt utility on a machine that has at least one server instance in an Oracle WebLogic Server domain; it cannot be run from a client.
Note:
Oracle recommends running the utility from the Administration Server domain directory or on the machine hosting the Administration Server and specifying a domain root directory.
java [-Dweblogic.RootDirectory=dirname] [-Dweblogic.management.allowPasswordEcho=true] weblogic.security.Encrypt [password]
Table 2-5 describes the arguments that are passed to the weblogic.security.Encrypt utility.
| Argument | Definition |
|---|---|
dirname
|
Optional. Oracle WebLogic Server domain directory in which the encrypted string will be used. If not specified, the default domain root directory is the current directory (the directory in which the utility is being run). |
weblogic.management.allowPasswordEcho |
Optional. Allows echoing characters entered on the command line. |
password
|
Optional. Cleartext string to be encrypted. If omitted from the command line, you will be prompted to enter a password. |
The utility returns an encrypted string using the encryption service of the domain located in the current directory.
java weblogic.security.Encrypt xxxxxx
{AES}yWv/i0qhfM4/IvzoghzjHj/xpJUkQPF8OWuSfh0f0Ss=
The utility returns an encrypted string using the encryption service of the specified domain location.
java -Dweblogic.RootDirectory=./mydomain weblogic.security.Encrypt xxxxxx
{AES}wr86u9Z5DHr+5p7WIbzTDSy4M/sl7EYnX/K5xzcarDQ=
The utility returns an encrypted string in the current directory, without echoing the password.
java weblogic.security.Encrypt
Password:
{AES}LIX8hoiStcAhph0PGCpveouw/0UO0lciODuj+TQh/bs=
The getProperty utility gives you details about your Java setup and your system. It takes no arguments.
$ java utils.getProperty -- listing properties -- user.language=en java.home=c:\java11\bin\.. awt.toolkit=sun.awt.windows.WToolkit file.encoding.pkg=sun.io java.version=1.1_Final file.separator=\ line.separator= user.region=US file.encoding=8859_1 java.vendor=Sun Microsystems Inc. user.timezone=PST user.name=mary os.arch=x86 os.name=Windows NT java.vendor.url=http://www.sun.com/ user.dir=C:\weblogic java.class.path=c:\weblogic\classes;c:\java\lib\cla... java.class.version=45.3 os.version=4.0 path.separator=; user.home=C:\
The host2ior utility obtains the Interoperable Object Reference (IOR) of an Oracle WebLogic Server.
The ImportPrivateKey utility is used to load a private key into a private keystore file.
$ java utils.ImportPrivateKey
-certfile <cert_file> -keyfile <private_key_file>
[-keyfilepass <private_key_password>]
-keystore <keystore> -storepass <storepass> [-storetype <storetype>]
-alias <alias> [-keypass <keypass>]
[-help]
Table 2-6 describes the arguments that are passed to the ImportPrivateKey utility.
Table 2-6 ImportPrivateKey Arguments
| Argument | Definition |
|---|---|
cert_file
|
The name of the certificate associated with the private key. |
private_key_file
|
The name of the generated private key file. |
private_key_password
|
The password for the private key. |
keystore
|
The name of the keystore file. A new keystore is created if one does not exist. |
storepass
|
The password for the keystore. |
storetype
|
The type (format) of the keystore. The keystore.type=jks You can specify another |
alias
|
The name that is used for looking up the certificate and private key being imported into the keystore. |
keypass
|
The password of the private key entry being imported into the keystore. If |
Note:
If you used CertGen to create a private key file protected by a password (-keyfilepass private_key_password), that password is the one required by ImportPrivateKey to extract the key from the key file and insert the key in the newly created keystore (which will contain both the certificate(s) from cert_file and the private key from private_key_file).
Use the following steps to:
Generate a certificate and private key using the CertGen utility
Create a keystore and store a private key using the ImportPrivateKey utility
Note:
By default, the CertGen utility looks for the CertGenCA.der and CertGenCAKey.der files in the current directory, or in the WL_HOME/server/lib directory, as specified in the weblogic.home system property or the CLASSPATH.
Alternatively, you can specify CA files on the command line. If you want to use the default settings, there is no need to specify CA files on the command line.
To generate a certificate:
Enter the following command to generate certificate files named testcert with private key files named testkey:
$ java utils.CertGen -keyfilepass mykeyfilepass -certfile testcert -keyfile testkey Generating a certificate with common name return and key strength 1024 issued by CA with certificate from CertGenCA.der file and key from CertGenCAKey.der file
Convert the certificate from DER format to PEM format.
$ java utils.der2pem CertGenCA.der
Concatenate the certificate and the Certificate Authority (CA).
$ cat testcert.pem CertGenCA.pem >> newcerts.pem
Create a new keystore named mykeystore and load the private key located in the testkey.pem file.
$ java utils.ImportPrivateKey -keystore mykeystore -storepass mypasswd -keyfile mykey -keyfilepass mykeyfilepass -certfile newcerts.pem -keyfile testkey.pem -alias passalias No password was specified for the key entry Key file password will be used Imported private key testkey.pem and certificate newcerts.pem into a new keystore mykeystore of type jks under alias passalias
Converts JHTML files to JSP files. Be sure to inspect the results carefully. Given the unpredictability of the JHTML code, jhtml2jsp will not necessarily produce flawless translations.
The output is a new JSP file named after the original file.
The HTTP servlets auto-generated from JSP pages differ from the regular HTTP servlets generated from JHTML. JSP servlets extend weblogic.servlet.jsp.JspBase, and so do not have access to the methods available to a regular HTTP servlet.
If your JHTML pages reference these methods to access the servlet context or config objects, you must substitute these methods with the reserved words in JSP that represent these implicit objects.
If your JHTML uses variables that have the same name as the reserved words in JSP, the tool will output a warning. You must edit your Java code in the generated JSP page to change the variable name to something other than a reserved word.
$ java weblogic.utils.jhtml2jsp [-d directory] filename.jhtml
Table 2-7 describes the argument that is passed to the jhtml2jsp tool.
JSP-specific compiler task. Use appc.
The logToZip utility searches an HTTP server log file, finds the Java classes loaded into it by the server, and creates an uncompressed .zip file that contains those Java classes. It is executed from the document root directory of your HTTP server.
To use this utility, you must have access to the log files created by the HTTP server.
$ java utils.logToZip logfile codebase zipfile
Table 2-8 describes the arguments that are passed to the logToZip utility.
| Argument | Definition |
|---|---|
logfile
|
Required. Fully-qualified pathname of the log file. |
codebase
|
Required. Code base for the applet, or |
zipfile
|
Required. Name of the |
The following example shows how a .zip file is created for an applet that resides in the document root itself, that is, with no code base:
$ cd /HTTP/Serv/docs $ java utils.logToZip /HTTP/Serv/logs/access "" app2.zip
The following example shows how a .zip file is created for an applet that resides in a subdirectory of the document root:
C:\>cd \HTTP\Serv C:\HTTP\Serv>java utils.logToZip \logs\applets\classes app3.zip
Use the MBean commands (CREATE, DELETE, GET, INVOKE, and SET) to administer MBeans. See "Editing Commands" in WebLogic Scripting Tool Command Reference.
The MulticastTest utility helps you debug multicast problems when configuring a WebLogic Cluster. The utility sends out multicast packets and returns information about how effectively multicast is working on your network. Specifically, MulticastTest displays the following types of information via standard output:
A confirmation and sequence ID for each message sent out by the current server.
The sequence and sender ID of each message received from any clustered server, including the current server.
A missed-sequenced warning when a message is received out of sequence.
A missed-message warning when an expected message is not received.
To use MulticastTest, start one copy of the utility on each node on which you want to test multicast traffic.
Tip:
Do NOT run the MulticastTest utility by specifying the same multicast address (the -a parameter) as that of a currently running WebLogic Cluster. The utility is intended to verify that multicast is functioning properly before starting your clustered WebLogic Servers.
For information about setting up multicast, see the configuration documentation for the operating system and hardware of the WebLogic Server host machine. For more information about configuring a cluster, see Using Clusters for Oracle WebLogic Server.
$ java utils.MulticastTest -n name -a address [-p portnumber] [-t timeout] [-s send]
Table 2-9 describes the arguments that are passed to the MulticastTest utility.
Table 2-9 MulticastTest Arguments
| Argument | Definition |
|---|---|
-n name
|
Required. A name that identifies the sender of the sequenced messages. Use a different name for each test process you start. |
-a address
|
The multicast address on which: (a) the sequenced messages should be broadcast; and (b) the servers in the clusters are communicating with each other. (The default is 237.0.0.1.) |
-p portnumber
|
Optional. The multicast port on which all the servers in the cluster are communicating. (The multicast port is the same as the listen port set for WebLogic Server, which defaults to 7001 if unset.) |
-t timeout
|
Optional. Idle timeout, in seconds, if no multicast messages are received. If unset, the default is 600 seconds (10 minutes). If a timeout is exceeded, a positive confirmation of the timeout is sent to |
-s send
|
Optional. Interval, in seconds, between sends. If unset, the default is 2 seconds. A positive confirmation of each message sent out is sent to |
$ java utils.MulticastTest -N server100 -A 237.155.155.1 Set up to send and receive on Multicast on Address 237.155.155.1 on port 7001 Will send a sequenced message under the name server100 every 2 seconds. Received message 506 from server100 Received message 533 from server200 I (server100) sent message num 507 Received message 507 from server100 Received message 534 from server200 I (server100) sent message num 508 Received message 508 from server100 Received message 535 from server200 I (server100) sent message num 509 Received message 509 from server100 Received message 536 from server200 I (server100) sent message num 510 Received message 510 from server100 Received message 537 from server200 I (server100) sent message num 511 Received message 511 from server100 Received message 538 from server200 I (server100) sent message num 512 Received message 512 from server100 Received message 539 from server200 I (server100) sent message num 513 Received message 513 from server100
The pem2der utility converts an X509 certificate from PEM format to DER format. The .der file is written in the same directory as the source .pem file.
$ java utils.pem2der pemFile
Table 2-10 describes the argument that is passed to the pem2der utility.
$ java utils.pem2der graceland_org.pem Decoding ................................................................ ................................................................ ................................................................ ................................................................ ................................................................
The WebLogic RMI compiler is a command-line utility for generating and compiling remote objects. Use weblogic.rmic to generate dynamic proxies on the client-side for custom remote object interfaces in your application, and to provide hot code generation for server-side objects. See "Using the WebLogic RMI Compiler" in Programming RMI for Oracle WebLogic Server.
The Schema utility lets you upload SQL statements to a database using the WebLogic JDBC drivers. For additional information about database connections, see Programming JDBC for Oracle WebLogic Server.
$ java utils.Schema driverURL driverClass [-u username] [-p password] [-verbose] SQLfile
Table 2-11 describes the arguments that are passed to the Schema utility.
| Argument | Definition |
|---|---|
driverURL
|
Required. URL for the JDBC driver. |
driverClass
|
Required. Pathname of the JDBC driver class. |
-u username
|
Optional. Valid username. |
-p password
|
Optional. Valid password for the user. |
-verbose |
Optional. Prints SQL statements and database messages. |
SQLfile
|
Required. Text file with SQL statements. |
The following code shows a Schema command line for the examples.utils package:
$ java utils.Schema
"jdbc:derby://localhost:1527/demo"
"org.apache.derby.jdbc.ClientDriver" -u examples
-p examples examples/utils/ddl/demo.ddl
utils.Schema will use these parameters:
url: jdbc:derby://localhost:1527/demo
driver: org.apache.derby.jdbc.ClientDriver
user: examples
password: examples
SQL file: examples/utils/ddl/demo.ddl
The servicegen Ant task takes as input an EJB JAR file or a list of Java classes, and creates all the needed Web Service components and packages them into a deployable EAR file.
Web Services are now a Java EE standard, which has resulted in many changes between 8.1 and 9.0 WebLogic Web Services.
For a complete list of Web Services Ant tasks, see "Ant Task Reference" in WebLogic Web Services Reference for Oracle WebLogic Server.
This Ant task executes build.xml files that are included within the FileSet. The task assumes that all of the files defined in FileSet are valid build files, and executes the Ant task of each of them.
Make certain that your FileSet filtering is correct. If you include the build.xml file that SearchAndBuildTask is being called from, you will be stuck in an infinite loop as this task will execute the top level build file—itself—forever.
<project name="all_modules" default="all" basedir=".">
<taskdef name="buildAll"
classname="weblogic.ant.taskdefs.build.SearchAndBuildTask"/>
<target name="all">
<buildAll>
<fileset dir="${basedir}">
<include name="**\build.xml"/>
<exclude name="build.xml"/>
</fileset>
</buildAll>
</target>
</project>
Generates a web-services.xml deployment descriptor file from the Java source file for a Java class-implemented WebLogic Web Service.
Web Services are now a Java EE standard, which has resulted in many changes between 8.1 and 9.0 WebLogic Web Services.
For a complete list of Web Services Ant tasks, see "Ant Task Reference" in WebLogic Web Services Reference for Oracle WebLogic Server.
The system utility displays basic information about your computer's operating environment, including the manufacturer and version of your JDK, your CLASSPATH, and details about your operating system.
$ java utils.system * * * * * * * java.version * * * * * * * 1.5.0_03 * * * * * * * java.vendor * * * * * * * * * * * * * * java.class.path * * * * * * * C:\Oracle\Middleware\wlserver_10.3\server\classes; C:\dev\src\build\JROCKI~2.0_0\lib\tools.jar; ... * * * * * * * os.name * * * * * * * Windows 2000 * * * * * * * os.arch * * * * * * * x86 * * * * * * * os.version * * * * * * * 5.0
WebLogic Server provides the ValidateCertChain utility to check whether or not an existing certificate chain will be rejected by WebLogic Server. The utility uses certificate chains from PEM files, PKCS-12 files, PKCS-12 keystores, and JKS keystores. A complete certificate chain must be used with the utility. The following is the syntax for the ValidateCertChain utility:
java utils.ValidateCertChain -file pemcertificatefilenamejava utils.ValidateCertChain -pem pemcertificatefilenamejava utils.ValidateCertChain -pkcs12store pkcs12storefilenamejava utils.ValidateCertChain -pkcs12file pkcs12filename passwordjava utils.ValidateCertChain -jks alias storefilename [storePass]
Example of valid certificate chain:
java utils.ValidateCertChain -pem zippychain.pemCert[0]: CN=zippy, OU=FORTESTINGONLY,O=MyOrganization,L=MyTown,ST=MyState,C=USCert[1]: CN=CertGenCAB,OU=FOR TESTINGONLY,O=MyOrganization,L=MyTown,ST=MyState,C=US Certificate chain appears valid
Example of invalid certificate chain:
java utils.ValidateCertChain -jks mykey mykeystoreCert[0]: CN=corba1, OU=FOR TESTING ONLY, O=MyOrganization,L=MyTown,ST=MyState,C=US CA cert not marked with critical BasicConstraint indicating it is a CACert[1]: CN=CACERT,OU=FOR TESTING ONLY, O=MyOrganization,L=MyTown,ST=MyState,C=USCertificate chain is invalid
When executed from the document root directory of your HTTP server, verboseToZip takes the standard output from a Java application run in verbose mode, finds the Java classes referenced, and creates an uncompressed .zip file that contains those Java classes.
$ java utils.verboseToZip inputFile zipFileToCreate
Table 2-12 describes the arguments that are passed to verboseToZip.
Table 2-12 verboseToZip Arguments
| Argument | Definition |
|---|---|
inputFile
|
Required. Temporary file that contains the output of the application running in verbose mode. |
zipFileToCreate
|
Required. Name of the |
This utility compiles and validates a Java EE EAR file, an EJB JAR file, or a WAR file for deployment.
For more information, see "Building Modules and Applications Using wlappc" in Developing Applications for Oracle WebLogic Server.
Use the wlcompile Ant task to invoke the javac compiler to compile your application's Java files in a split development directory structure. See "Building Applications in a Split Development Directory" in Developing Applications for Oracle WebLogic Server.
The wlconfig Ant task enables you to configure a WebLogic Server domain by creating, querying, or modifying configuration MBeans on a running Administration Server instance. For complete documentation on this Ant task, see "Using Ant Tasks to Configure a WebLogic Server Domain" in Developing Applications for Oracle WebLogic Server.
The wldeploy Ant task enables you to perform Deployer functions (see Deployer) using attributes specified in an Ant task. See "Deploying and Packaging from a Split Development Directory" in Developing Applications for Oracle WebLogic Server.
You use the wlpackage Ant task to package your split development directory application as a traditional EAR file that can be deployed to WebLogic Server. See "Deploying and Packaging from a Split Development Directory" in Developing Applications for Oracle WebLogic Server.
The wlserver Ant task enables you to start, reboot, shutdown, or connect to a WebLogic Server instance. The server instance may already exist in a configured WebLogic Server domain, or you can create a new single-server domain for development by using the generateconfig=true attribute. For complete documentation on this Ant task, see "Starting Servers and Creating Domains Using the wlserver Ant Task" in Developing Applications for Oracle WebLogic Server.
The wsdl2Service Ant task is a Web Services tool that takes as input an existing WSDL file and generates the Java interface that represents the implementation of your Web Service and the web-services.xml file that describes the Web Service. See "Developing WebLogic Web Services Starting From a WSDL File: Main Steps" in Getting Started With JAX-WS Web Services for Oracle WebLogic Server.
The wsdlgen Ant task is a Web Services tool that generates a WSDL file from the EAR and WAR files that implement your Web Service.
Web Services are now a Java EE standard, which has resulted in many changes between 8.1 and 9.0 WebLogic Web Services.
For a complete list of Web Services Ant tasks, see "Ant Task Reference" in WebLogic Web Services Reference for Oracle WebLogic Server.
Use the Web Services wspackage Ant task to package the various components of a WebLogic Web Service into a new deployable EAR file and add extra components to an already existing EAR file.
Web Services are now a Java EE standard, which has resulted in many changes between 8.1 and 9.0 WebLogic Web Services.
For a complete list of Web Services Ant tasks, see "Ant Task Reference" in WebLogic Web Services Reference for Oracle WebLogic Server.