The following sections describe how to start and stop WebLogic Server instances and configure WebLogic Server domains using WebLogic Ant tasks that you can include in your development build scripts:
WebLogic Server provides a pair of Ant tasks to help you perform common configuration tasks in a development environment. The configuration tasks enable you to start and stop WebLogic Server instances as well as create and configure WebLogic Server domains.
When combined with other WebLogic Ant tasks, you can create powerful build scripts for demonstrating or testing your application with custom domains. For example, a single Ant build script can:
wlcompile
, wlappc
, and Web Services Ant tasks.wlserver
Ant task.wlconfig
Ant task.wldeploy
Ant task.
The sections that follow describe how to use the configuration Ant tasks, wlserver
and wlconfig
.
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.
When you use the wlserver
task in an Ant script, the task does not return control until the specified server is available and listening for connections. If you start up a server instance using wlserver, the server process automatically terminates after the Ant VM terminates. If you only connect to a currently-running server using the wlserver
task, the server process keeps running after Ant completes.
The wlserver
WebLogic Server Ant task extends the standard java
Ant task (org.apache.tools.ant.taskdefs.Java
). This means that all the attributes of the java
Ant task also apply to the wlserver
Ant task. For example, you can use the output
and error
attributes to specify the name of the files to which output and standard errors of the wlserver
Ant task is written, respectively. For full documentation about the attributes of the standard java Ant task, see
Java on the
Apache Ant site.
On Windows NT, execute the setWLSEnv.cmd
command, located in the directory WL_HOME\server\bin
, where WL_HOME
is the top-level directory of your WebLogic Server installation.
On UNIX, execute the setWLSEnv.sh
command, located in the directory WL_HOME/server/bin
, where WL_HOME
is the top-level directory of your WebLogic Server installation.
Note: | The wlserver task is predefined in the version of Ant shipped with WebLogic Server. If you want to use the task with your own Ant installation, add the following task definition in your build file: |
<taskdef name="wlserver" classname="weblogic.ant.taskdefs.management.WLServer"/>
wlserver
task in the build script to start, shutdown, restart, or connect to a server. See wlserver Ant Task Reference for information about wlserver
attributes and default behavior.build.xml
file by typing ant
in the staging directory, optionally passing the command a target argument:prompt> ant
Use ant -verbose
to obtain more detailed messages from the wlserver
task.
The following shows a minimal wlserver
target that starts a server in the current directory using all default values:
<target name="wlserver-default">
<wlserver/>
</target>
This target connects to an existing, running server using the indicated connection parameters and username/password combination:
<target name="connect-server">
<wlserver host="127.0.0.1" port="7001" username="weblogic" password="weblogic" action="connect"/>
</target>
This target starts a WebLogic Server instance configured in the config
subdirectory:
<target name="start-server">
<wlserver dir="./config" host="127.0.0.1" port="7001" action="start"/>
</target>
This target creates a new single-server domain in an empty directory, and starts the domain's server instance:
<target name="new-server">
<delete dir="./tmp"/>
<mkdir dir="./tmp"/>
<wlserver dir="./tmp" host="127.0.0.1" port="7001"
generateConfig="true" username="weblogic" password="weblogic" action="start"/>
</target>
The following table describes the attributes of the wlserver
Ant task.
A WebLogic Server instance is uniquely identified by its protocol, host, and port values, so if you use this set of attributes to specify the server you want to start, shutdown or reboot, you do not need to specify its actual name using the
servername attribute. The only exception is when you want to shutdown the Administration server; in this case you must specify this attribute.
|
|||||
The username of an administrator account. If you omit both the
username and password attributes, wlserver attempts to obtain the encrypted username and password values from the boot.properties file. See
Boot Identity Files in the Managing Server Startup and Shutdown for more information on boot.properties .
|
|||||
The password of an administrator account. If you omit both the
username and password attributes, wlserver attempts to obtain the encrypted username and password values from the boot.properties file. See
Boot Identity Files in the Managing Server Startup and Shutdown for more information on boot.properties .
|
|||||
Development mode enables a WebLogic Server instance to automatically deploy and update applications that are in the
domain_name /autodeploy directory (where domain_name is the name of a WebLogic Server domain). In other words, development mode lets you use auto-deploy. Production mode disables the auto-deployment feature. See Deploying Applications and Modules for more information.
Valid values for this attribute are
True and False . The default value is False (which means that by default a server instance boots in development mode.)
|
|||||
This optional attribute is used in conjunction with the
action="shutdown" attribute to perform a forced shutdown. For example:
|
|||||
Specifies whether the
wlserver Ant task, if run against an 8.1 (or previous) domain, should implicitly upgrade it to version 9.2.
Valid values are
true or false . The default value is false , which means that the Ant task does not implicitly upgrade the domain, but rather, will fail with an error indicating that the domain needs to be upgraded to version 9.2 of WebLogic Server.
For more information about upgrading domains, see
Upgrading WebLogic Application Environments.
|
|||||
The value of this attribute must be a valid XML file that conforms to the XML schema as defined in the
BEA WebLogic Server 9.2 Domain Configuration Schema Reference.
|
|||||
Specifies whether to use the
boot.properties file when starting a WebLogic Server instance. If this attribute is set to true , WebLogic Server uses the username and encrypted password stored in the boot.properties file to start rather than any values set with the username and password attributes.
Valid values for this attribute are |
|||||
The following sections describe how to use the wlconfig
Ant task to configure a WebLogic Server domain.
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. Specifically, wlconfig
enables you to:
WARNING: | The wlconfig Ant task works only against MBeans that are in the compatibility MBean server, which has been deprecated as of version 9.0 of WebLogic Server. |
WARNING: | In particular, the wlconfig Ant task uses the deprecated BEA proprietary API weblogic.management.MBeanHome to access WebLogic MBeans, the same as it did in Version 8.1 of WebLogic Server. The Ant task does not use the standard JMX interface (javax.management.MBeanServerConnection ) to discover MBeans. |
WARNING: | This means that the only MBeans that you can access using wlconfig are those listed under the Deprecated MBeans category in the
WebLogic Server MBean Reference. |
Note: | The wlconfig task is predefined in the version of Ant shipped with WebLogic Server. If you want to use the task with your own Ant installation, add the following task definition in your build file: |
<taskdef name="wlconfig" classname="weblogic.ant.taskdefs.management.WLConfig"/>
wlconfig
is commonly used in combination with wlserver
to configure a new WebLogic Server domain created in the context of an Ant task. If you will be using wlconfig
to configure such a domain, first use wlserver
attributes to create a new domain and start the WebLogic Server instance.wlconfig
task to connect to the Administration Server for a domain. For example:<target name="doconfig">
<wlconfig url="t3://localhost:7001" username="weblogic"
password="weblogic">
</target>
create
, delete
, get
, set
, and query
elements to configure the domain.build.xml
file by typing ant
in the staging directory, optionally passing the command a target argument:prompt> ant doconfig
Use ant -verbose
to obtain more detailed messages from the wlconfig
task.
The following sections provide sample Ant build scripts for using the wlconfig
Ant task.
This example shows a single build.xml
file that creates a new domain using wlserver
and performs various domain configuration tasks with wlconfig
. The configuration tasks set up domain resources required by the Avitek Medical Records sample application.
The script starts by creating the new domain:
<target name="medrec.config">
<mkdir dir="config"/>
<wlserver username="a" password="a" servername="MedRecServer"
domainname="medrec" dir="config" host="localhost" port="7000"
generateconfig="true"/>
The script then starts the wlconfig
task by accessing the newly-created server:
<wlconfig url="t3://localhost:7000" username="a" password="a">
Within the wlconfig
task, the query
element runs a query to obtain the Server MBean object name, and stores this MBean in the ${medrecserver}
Ant property:
<query domain="medrec" type="Server" name="MedRecServer"
property="medrecserver"/>
The script the uses a create
element to create a new JDBC connection pool in the domain, storing the object name in the ${medrecpool}
Ant property. Nested set
elements in the create
operation set attributes on the newly-created MBean. The new pool is target to the server using the ${medrecserver}
Ant property set in the query above:
<create type="JDBCConnectionPool" name="MedRecPool"
property="medrecpool">
<set attribute="CapacityIncrement" value="1"/>
<set attribute="DriverName"
value="com.pointbase.jdbc.jdbcUniversalDriver"/>
<set attribute="InitialCapacity" value="1"/>
<set attribute="MaxCapacity" value="10"/>
<set attribute="Password" value="MedRec"/>
<set attribute="Properties" value="user=MedRec"/>
<set attribute="RefreshMinutes" value="0"/>
<set attribute="ShrinkPeriodMinutes" value="15"/>
<set attribute="ShrinkingEnabled" value="true"/>
<set attribute="TestConnectionsOnRelease" value="false"/>
<set attribute="TestConnectionsOnReserve" value="false"/>
<set attribute="URL"
value="jdbc:pointbase:server://localhost/demo"/>
<set attribute="Targets" value="${medrecserver}"/>
</create>
Next, the script creates a JDBC TX DataSource using the JDBC connection pool created above:
<create type="JDBCTxDataSource" name="Medical Records Tx DataSource">
<set attribute="JNDIName" value="MedRecTxDataSource"/>
<set attribute="PoolName" value="MedRecPool"/>
<set attribute="Targets" value="${medrecserver}"/>
</create>
The script creates a new JMS connection factory using nested set
elements:
<create type="JMSConnectionFactory" name="Queue">
<set attribute="JNDIName" value="jms/QueueConnectionFactory"/>
<set attribute="XAServerEnabled" value="true"/>
<set attribute="Targets" value="${medrecserver}"/>
</create>
A new JMS JDBC store is created using the MedRecPool
:
<create type="JMSJDBCStore" name="MedRecJDBCStore"
property="medrecjdbcstore">
<set attribute="ConnectionPool" value="${medrecpool}"/>
<set attribute="PrefixName" value="MedRec"/>
</create>
When creating a new JMS server, the script uses a nested create
element to create a JMS queue, which is the child of the JMS server:
<create type="JMSServer" name="MedRecJMSServer">
<set attribute="Store" value="${medrecjdbcstore}"/>
<set attribute="Targets" value="${medrecserver}"/>
<create type="JMSQueue" name="Registration Queue">
<set attribute="JNDIName" value="jms/REGISTRATION_MDB_QUEUE"/>
</create>
</create>
This script creates a new mail session and startup class:
<create type="MailSession" name="Medical Records Mail Session">
<set attribute="JNDIName" value="mail/MedRecMailSession"/>
<set attribute="Properties"
value="mail.user=joe;mail.host=mail.mycompany.com"/>
<set attribute="Targets" value="${medrecserver}"/>
</create>
<create type="StartupClass" name="StartBrowser">
<set attribute="Arguments" value="port=${listenport}"/>
<set attribute="ClassName"
value="com.bea.medrec.startup.StartBrowser"/>
<set attribute="FailureIsFatal" value="false"/>
<set attribute="Notes" value="Automatically starts a browser on server boot."/>
<set attribute="Targets" value="${medrecserver}"/>
</create>
Finally, the script obtains the WebServer
MBean and sets the log filename using a nested set
element:
<query domain="medrec" type="WebServer" name="MedRecServer">
<set attribute="LogFileName" value="logs/access.log"/>
</query>
</wlconfig>
</target>
The query
element does not need to specify an MBean name when nested within a query
element:
<target name="queryDelete">
<wlconfig url="${adminurl}" username="${user}" password="${pass}"
failonerror="false">
<query query="${wlsdomain}:Name=MyNewServer2,*"
property="deleteQuery">
<delete/>
</query>
</wlconfig>
</target>
The set
element allows you to set an attribute value to multiple object names stored in Ant properties. For example, the following target stores the object names of two servers in separate Ant properties, then uses those properties to assign both servers to the target attribute of a new JDBC Connection Pool:
<target name="multipleJDBCTargets">
<wlconfig url="${adminurl}" username="${user}" password="${pass}">
<query domain="mydomain" type="Server" name="MyServer"
property="myserver"/>
<query domain="mydomain" type="Server" name="OtherServer"
property="otherserver"/>
<create type="JDBCConnectionPool" name="sqlpool" property="sqlpool">
<set attribute="CapacityIncrement" value="1"/>
[.....]
<set attribute="Targets" value="${myserver};${otherserver}"/>
</create>
</wlconfig>
</target>
The following sections describe the attributes and elements that can be used with wlconfig
.
The following table describes the main attributes of the wlconfig
Ant task.
To avoid having the plain text password appear in the build file or in process utilities such as
ps , first store a valid username and encrypted password in a configuration file using the WebLogic Scripting Tool (WLST) storeUserConfig command. Then omit both the username and password attributes in your Ant build file. When the attributes are omitted, wlconfig attempts to login using values obtained from the default configuration file.
If you want to obtain a username and password from a non-default configuration file and key file, use the
userconfigfile and userkeyfile attributes with wlconfig .
See the command reference for
storeUserConfig in the
WLST Command and Variable Reference for more information on storing and encrypting passwords.
|
|||
Specifies the location of a user configuration file to use for obtaining the administrative username and password. Use this option, instead of the
username and password attributes, in your build file when you do not want to have the plain text password shown in-line or in process-level utilities such as ps .
Before specifying the
userconfigfile attribute, you must first generate the file using the WebLogic Scripting Tool (WLST) storeUserConfig command as described in the
WLST Command and Variable Reference.
|
|||
Specifies the location of a user key file to use for encrypting and decrypting the username and password information stored in a user configuration file (the
userconfigfile attribute).
Before specifying the
userkeyfile attribute, you must first generate the key file using the WebLogic Scripting Tool (WLST) storeUserConfig command as described in the
WLST Command and Variable Reference.
|
wlconfig
also has several elements that can be nested to specify configuration options:
The create
element creates a new MBean in the WebLogic Server domain. The wlconfig
task can have any number of create
elements.
A create
element can have any number of nested set
elements, which set attributes on the newly-created MBean. A create
element may also have additional, nested create
elements that create child MBeans.
The create
element has the following attributes.
|
The delete
element removes an existing MBean from the WebLogic Server domain. delete
takes a single attribute:
The set
element sets MBean attributes on a named MBean, a newly-created MBean, or on MBeans retrieved as part of a query. You can include the set
element as a direct child of the wlconfig
task, or nested within a create
or query
element.
The set
element has the following attributes:
You can specify multiple object names (stored in Ant properties) as a value by delimiting the entire value list with quotes and separating the object names with a semicolon. See Example of Setting Multiple Attribute Values.
|
|||||
This attribute specifies the JMX domain name for Security MBeans and third-party SPI MBeans. It is not required for administration MBeans, as the domain corresponds to the WebLogic Server domain.
|
The get
element retrieves attribute values from an MBean in the WebLogic Server domain. The wlconfig
task can have any number of get
elements.
The get
element has the following attributes.
The query
elements finds MBean that match a search pattern.
The query element supports the following nested child elements:
set
—performs set operations on all MBeans in the result set.get
—performs get operations on all MBeans in the result set.create
—each MBean in the result set is used as a parent of a new MBean.delete
—performs delete operations on all MBeans in the result set.invoke
—invokes all matching MBeans in the result set.
wlconfig
can have any number of nested query
elements.
query
has the following attributes:
The invoke
element invokes a management operation for one or more MBeans. For WebLogic Server MBeans, you usually use this command to invoke operations other than the get
Attribute
and set
Attribute
that most WebLogic Server MBeans provide.
The invoke
element has the following attributes.
Use the libclasspath
Ant task to build applications that use libraries, such as application libraries and web libraries.
To use the task with your own Ant installation, add the following task definition in your build file:
<taskdef name="libclasspath" classname="weblogic.ant.taskdefs.build.LibClasspathTask"/>
The following sections describe the attributes and elements that can be used with the libclasspath
Ant task.
The following table describes the main attributes of the libclasspath
Ant task.
libclasspath
also has two elements that can be nested to specify configuration options. At least one of the elements is required when using the libclasspath
Ant task:
The following attribute is required when using this element:
dir
—Specifies that all files in this directory are registered as available libraries.
The following attribute is required when using this element:
file
—Register this file as an available library.
This section provides example code of a libclasspath
Ant task:
.
.
.
<taskdef name="libclasspath" classname="weblogic.ant.taskdefs.build.LibClasspathTask"/>
<!-- Builds classpath based on libraries defined in weblogic-application.xml. -->
<target name="init.app.libs">
<libclasspath basedir="${src.dir}" tmpdir="${tmp.dir}"classpathproperty
="app.lib.classpath">
<librarydir dir="${weblogic.home}/common/deployable-libraries/"/>
</libclasspath>
<echo message="app.lib.claspath is ${app.lib.classpath}" level="info"/>
</target>
.
.
.