Weblogic deployment through wldeploy ant task

There are different types and ways to deploy the applications in weblogic .For more information please go through the link. Different Types of Deployments in Weblogic

How to deploy applications with wldeploy ant task in weblogic ?

Weblogic server provides the wldeploy ant task to perform the deployment operations.The wldeploy Ant task  performs weblogic.Deployer functions using attributes specified in an Ant XML file.

How to use the wldeploy ?

To use the wldeploy ant task , ANT should be installed. Refer the link How to install Apache ANT .

• Verify the ANT installation as below

               -bash-3.2$ ./ant -version
                Apache Ant(TM) version 1.9.4 compiled on April 29 2014
                -bash-3.2$

• If you get the error JAVA_HOME error as below 

             -bash-3.2$  ./ant -version
             Error: JAVA_HOME is not defined correctly.
             We cannot execute /opt/java/32bit/jdk1.6.0_31/bin/java

• Set the JAVA_HOME  as below

            -bash-3.2$ export JAVA_HOME=/opt/install/java/32bit/jdk1.6.0_31
            -bash-3.2$ echo $JAVA_HOME
            /opt/install/java//32bit/jdk1.6.0_31

• Create the build.xml as below

           <project name="weblogic_deployment" default="deploy">
           <target name="deploy">
              <wldeploy
                      action="deploy" verbose="true" debug="true"
                      name="example-App" source="/opt/data/applications/example-App.war"
                      user="weblogic-user" password="weblogic-password"
                      adminurl="t3://weblogic-admin-host:7001" targets="server-name"  />
              </target>
             </project>

•  Set the weblogic environment variables , otherwise will get the below type of error.

    -bash-3.2$ ./ant deploy
        Buildfile: /opt/data/ant/apache-ant-1.9.4/bin/build.xml
       deploy:
       BUILD FAILED
       /opt/data/ant/apache-ant-1.9.4/bin/build.xml:8: Problem: failed to create task or type wldeploy
       Cause: The name is undefined.
       Action: Check the spelling.
       Action: Check that any custom tasks/types have been declared.
       Action: Check that any <presetdef>/<macrodef> declarations have taken place.
       Total time: 0 seconds

• Set the weblogic domain environment variables as below 

          -bash-3.2$ . /opt/weblogic/domain/weblogicdomain/bin/setDomainEnv.sh
           Note: Here /opt/weblogic/domain/weblogicdomain is weblogic domain home

• Run the ant script as 

           -bash-3.2$ ./ant deploy

Issues we may get during the deployment through wldeploy ant task

BUILD FAILED
weblogic.management.ManagementException: [Deployer:149163]The domain edit lock is owned by another session in non-exclusive mode - this deployment operation requires exclusive access to the edit lock and hence cannot proceed. If you are using "Automatically Aquire Lock and Activate Changes" in the console, then the lock will expire shortly so retry this operation.

Solution 2 : Wait until Lock& Edit available or release the Configuration changes to obtain the lock.

Solution 2 : use the usenonexclusivelock="true" to build.xml to avoid the error.

Note: If we use this option  ant will not through error but gives the warning as 

[wldeploy] [BasicOperation.execute():445] : Initiating deploy operation for app, example-App , on targets:

 [wldeploy] [BasicOperation.execute():447] :    server-name

 [wldeploy] Task 14 initiated: [Deployer:149026]deploy application example-App on server-name.

 [wldeploy] Operation is pending and will be activated or cancelled when the ongoing edit session is activated or cancelled.

• Once the activate changes done deployment done other wise changes will not reflect.

WLST script to change the weblogic admin password

WLST script to change the weblogic admin password

Note: This will work not only for admin server also works for other users present in DefaultAuthenticator

Prepare the shell script to set up the environmental variables and to invoke the wlst

PasswordChange.sh
----------------------------------------

#WL_HOME="Weblogic Home"
WL_HOME=/usr/weblogic/wlserver_10.3"

#JAVA_HOME="java Home"
JAVA_HOME="/usr/java"

# set up common environment
. "${WL_HOME}/server/bin/setWLSEnv.sh"

"${JAVA_HOME}/bin/java"  weblogic.WLST PasswordChange.py

PasswordChange.properties
-------------------------------------------

Weblogic_Admin_URL=t3://weblogic.com:9001
Weblogic_username=weblogic
Weblogic_password=weblogiccurrent
New_Weblogic_password=newPassword
domainName=weblogicdomainname

PasswordChange.py
-------------------------------------------
loadProperties("PasswordChange.properties")
connect(Weblogic_username,Weblogic_password,Weblogic_Admin_URL)
cd('/SecurityConfiguration/'+domainName+'/Realms/myrealm/AuthenticationProviders/DefaultAuthenticator')

cmo.resetUserPassword(Weblogic_username,New_Weblogic_password)

disconnect()

exit()

• Changes will reflect immediately so no need to restart the server.
• Update the new password in boot.properties if exist to avoid issue during the server start up.
• we can also reset the user password through admin console
• Navigate to security Relams --> myrelam -->users and groups
• select the user and update the new password

Weblogic Cluster constraints

It specifies that deployments targeted to a cluster succeed only if all servers in the cluster are running.

By default, cluster constraints are disabled and deployment is attempted only on the servers that are reachable at the time of deployment from the Administration Server. Any servers that have been shut down or are temporarily partitioned from the Administration Server will retrieve the deployment during server startup .

We can enable or disable from weblogic admin console.
Enabling Cluster Constrains
Click on Domain name -->select the "Enable Cluster Constraints" check box--> save the changes .
Disabling Cluster Constrains
Click on Domain name -->uncheck  the "Enable Cluster Constraints" --> save the changes .

Cluster constrains can also set through application by adding below parameter to weblogic.xml file.
   <session-descriptor>
   <persistent-store-type>replicated_if_clustered</persistent-store-type>
   </session-descriptor>

Weblogic Datasources

There are 3 types of data sources in 10.3.5

•  Generic data source
•  Grid Link datasource
•  Mutli datasource

Datasource: contains pool of database connections that are created when datasource instance is created i.e.

A JDBC data source is an object bound to the JNDI tree that provides database connectivity through a pool of JDBC connections. Applications can look up a data source on the JNDI tree and then borrow a database connection from a data source.

•  When it is deployed or targeted
•  Server start-up

Multi Datasource: Abstraction around data source to provide load balancing or failover for datasource which are part of Multi Datasource

We can create the datasource as follows

•  By Admin Console
•  By WLST Script
• By Programmatically using JMX API (by Developer)

System v/s Application JDBC Module – JDBC Modules created by Administrator using Console or WLST are called as System JDBC module where as JDBC module created by developer using WebLogic Workshop, other IDE (Integrated Development Environment) or XML editor are called as Application JDBC Module.

<jdbc-system-resource>

    <name>JDBC Data Source-test</name>

    <target>weblogiccluster</target>

    <descriptor-file-name>jdbc/JDBC_Data_Source-test-0556-jdbc.xml</descriptor-file-name>

  </jdbc-system-resource>

Note:If we create the data source  related xml file will be created in conf/jdbc folder .Xml file contains the all information like connection pools,username, passwords and targets .... etc.

Grid Link datasource

A single GridLink data source provides connectivity between WebLogic Server and an Oracle Database service targeted to an Oracle RAC cluster. It uses the Oracle Notification Service (ONS) to adaptively respond to state changes in an Oracle RAC instance

A GridLink data source includes the features of generic data sources plus the following support for Oracle RAC:

•  "Fast Connection Failover"
• "Runtime Connection Load Balancing"
•  "Graceful Handling for Oracle RAC Outages"
•  "XA Affinity"
• "SCAN Addresses"
• "Secure Communication using Oracle Wallet."

Starting Weblogic managed server without node manager

We can start Weblogic managed server instance using the startManagedWebLogic

Windows : startManagedWebLogic.cmd

Solaris/Linex : startManagedWebLogic.sh

Syntax to start the managed server is "startManagedWebLogic.cmd server_name admin_url"
            server_name is the name of the Managed Server
            admin_url is the url used to access the Administration Server for the domain.

For example: startManagedWebLogic.cmd Server1 http://localhost:7001

startManagedWebLogic.cmd command collects the managed server name and internally call the "startWebLogic.cmd" to start the managed server.

startManagedWebLogic present in Domain home bin folder

%DOMAIN_HOME%\bin\ startManagedWebLogic.cmd

$DOMAIN_HOME/bin/startManagedWebLogic.sh

Note: 

• If we do not mention boot.properties it will ask the Admin server username and password.
• If we mention the boot.properties script don't ask the Admin server username and password.

Disadvantage: Server will shut down if we press CTL + C , So we need to start the process as nohub.

Weblogic Start up arguments

Enabling gc logs to  weblogic managed server

• -Xloggc:/data/Weblogic/logs/gc.log

Data source password change with out restart the web logic server

After we update system resources such as JDBC data sources, JMS modules, and diagnostic modules, we can redeploy them.

To update an application:

In the left pane of the Administration Console, select the domain that contains the system resources we want to redeploy.

In the right pane, click Control.

Click System Resources.

Select the check box next to the name of the system resources you want to redeploy.

Click Redeploy to redeploy the resources.

Click Yes to confirm our decision.

Making weblogic server as load balancing webserver

Making weblogic server as load balancing webserver


we can use the weblogic server as webserver by deploying a web application in weblogic server .
web application weblogic.xml and web.xml files should contains the below mentioned tags .
weblogic server details  need to be mention in WebLogicCluster parameter

  <init-param>
      <param-name>WebLogicCluster</param-name>
      <param-value>localhost:7003|localhost:7005</param-value>
    </init-param>

For example if you have one standalone  server and two  servers  in a cluster and Deployed the web application in standalone managed server .

If the request comes to stand alone  server it will send the request to the clustered servers.
weblogic.servlet.proxy.HttpClusterServlet servlet class is responsible to serve the requests.

web.xml
------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
 <servlet>
    <servlet-name>HttpClusterServlet</servlet-name>
    <servlet-class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>
    <init-param>
      <param-name>WebLogicCluster</param-name>
      <param-value>localhost:7003|localhost:7005</param-value>
    </init-param>
     
  </servlet>
  <servlet-mapping>
    <servlet-name>HttpClusterServlet</servlet-name>
    <url-pattern>/</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>HttpClusterServlet</servlet-name>
    <url-pattern>*.jsp</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>HttpClusterServlet</servlet-name>
    <url-pattern>*.htm</url-pattern>
  </servlet-mapping>
  <servlet-mapping>
    <servlet-name>HttpClusterServlet</servlet-name>
    <url-pattern>*.html</url-pattern>
  </servlet-mapping>
</web-app>


weblogic.xml file
------------------
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">
<weblogic-web-app>
    <context-root>/</context-root>
</weblogic-web-app>

Weblogic Terminology

• Domain: is a logically related group of WebLogic Server resources .A domain is an interrelated set of WebLogic Server resources that are managed as a unit.

• Administration Server: The server instance which configures, manages, and monitors all other server instances and resources in the domain. An Administration Server is a WebLogic Server instance that maintains configuration data for a domain.

• Managed Server: is a WebLogic Server instance that runs deployed applications.
• When a Managed Server starts up, it connects to the domain's Administration Server to synchronize its configuration document with the document that the Administration Server maintains.You can start a Managed Server even if the Administration Server is not running. In this case, the Managed Server uses a local copy of the domain’s configuration files for its starting configuration and then periodically attempts to connect with the Administration Server. When it does connect, it synchronizes its configuration state with that of the Administration Server.

•  If a Managed Server cannot connect to the Administration Server during start up, it can retrieve its configuration by reading its locally cached configuration data from the config directory.

• A Managed Server that starts in this way is running in Managed Server Independence (MSI) mode. By default, MSI mode is enabled.

• All Managed Servers in a cluster must reside in the same domain; you cannot split a cluster over multiple domains.
•  All Managed Servers in a domain must run the same version of the WebLogic Server software. The Administration Server may run either the same version as the Managed Servers in the domain, or a later service pack.
• Each Managed Server maintains a copy of the domain’s configuration files. This copy is read-only and can be updated only as part of a change management process.

•  When the Administration Server starts up, it saves a JAR file named config-booted.jar that contains the configuration files. When you make changes to the configuration files, the old files are saved in the configArchive directory under the domain directory, in a JAR file with a sequentially-numbered name like config-1.jar.
• Configuration changes that can take effect without a server restart are sometimes referred to as dynamic changes.

           Ex: if you change a Managed Server’s Listen Port value, the new port will not be used until the next time you start the Managed Server. The updated value is stored in config.xml, but the run time value is not affected.

• configuration changes that require a server restart are sometimes referred to as non-dynamic changes
• We can't start the server when it is in ADMIN mode, we can Resume the server to start.
• We can Shutdown the server which is in ADMIN Mode.
• The Administration Console is a browser-based Web application that allows you to configure and monitor your WebLogic Server domain, server instances, and running applications and their associated resources. You can also use the Administration Console to create new server instances and clusters and tune application descriptors

Types of HTTP Session Replication

Types of HTTP Session Replication

There are five different implementations of session persistence:

Memory (single-server, non-replicated): When you use memory-based storage, all session information is stored in memory and is lost when you stop and restart WebLogic Server.

File system persistence: Session information is stored in a file under the PersistentStoreDir specified.

JDBC persistence: Session information is stored in a database table.

Cookie-based session persistence: Session information is stored in a cookie.

In-memory replication (across a cluster): Session data is copied from one server instance to another into memory.

Thread Dump Taking Procedure

Taking Thread Dump:

1)                        Syntax:  kill -3 <ProcessID>

The Output of the Thread Dump will be generated in the Server STDOUT fie

2) Simplest option to take Thread Dump is:

Login to AdminConsole—>Server —> Monitoring —> Threads

3) Through WLST you need to write the WLST script like “AdminThreadDump.py”

In this case you will see the Thread Dumps on the Same Shell prompt….

Not need to look into the Server STDOUT

                           connect('weblogic','weblogic','t3://localhost:7001')

                           cd ('Servers')

                           ls()

                           cd ('AdminServer')

                           ls()

                           threadDump()

                           cd('..')

                           cd('ManagedServerOne')

                           threadDump()

Now open a command Shell and then run the “setWLSEnv.sh”

then run the WLST script like:

java weblogic.WLST AdminThreadDump.py

or

java weblogic.WLST /opt/bea/MyScripts/AdminThreadDump.py

 

Different Types of Deployments in weblogic

Stage mode
                      The Administration Server copies the archive files from their source location to a location on each of the targeted Managed Servers that deploy the archive. For example, if you deploy a J2EE Application to three servers in a cluster, the Administration Server copies the application archive files to each of the three servers. Each server then deploys the J2EE Application using its local copy of the archive files.

Stage mode is the default mode when deploying to more than one WebLogic Server instance.

Nostage mode

                   The Administration Server does not copy the archive files from their source location. Instead, each targeted server must access the archive files from a single source directory for deployment. For example, if you deploy a J2EE Application to three servers in a cluster, each server must be able to access the same application archive files (from a shared or network-mounted directory) to deploy the application.
Nostage mode is the default mode when deploying only to the Administration Server (for example, in a single-server domain). You can also select nostage mode if you run a cluster of server instances on the same machine.

 External_stage mode

                                External_stage mode is similar to stage mode, in that the deployment files must reside locally to each targeted server. However, the Administration Server does not automatically copy the deployment files to targeted servers in external_stage mode; instead, you must manually copy the files, or use a third-party application to copy the files for you.

Weblogic supports following type of deployment unit

a) EAR file (Enterprise Archive)

b) WAR file (Web Archive)

c) JAR files, EJB (Enterprise Java Beans)

d) RAR (Resource Adapter/Connector )

e) Web Services (WAR/JAR)

f) J2EE Library

g) CAR (Client Application Archive)


Tools used to deploy/configure applications

1) weblogic.Deployer – command line interface

2) Administration Console – Web based interface

3) WLST(WebLogic Scripting Tool) – command line tool to automate deployment configuration and operation

4) Tool for developers (wldeploy, weblogic.PlanGenerator, API, autodeploy)

Refer the links

➤ How to deploy applications with wldeploy