Weblogic Plugin to Set Deployment Order

WebLogic Server 12 has updates to the plugin that allow features such as being able to start/stop servers as well as run WLST scripting. The reason the WLST scripting is a beneficial feature is that the plugin is being used deploy all assets to a target environment (like wars, optional packages, and resources). In deploying all these resources through a build script, it becomes necessary to set the deployment order when assets have a dependency on a resource already being available prior to the asset being started during deployment or start-up of the managed server.

In order to modify the deployment order, a WLST script has to be used because the WebLogic Server 12 plugin does not support setting the deployment order through the maven script. So in order to utilize the newer WebLogic Server 12 maven plugin, it an install of WebLogic Server 12 so that it can utilize the install for running WLST scripts and other functioanility.

In the use case, the servers that exist within the environments is running 11g, however, in order to take advantage of this new feature, the build management system needs access to WebLogic Server 12c. As mentioned previously, this means that WebLogic Server 12 is installed on the build management box (in this case Hudson), so that the Hudson jobs have access to the install for WLST. The tests were ran utilizing the 12c version of the plugin to modify deployment orders on the 11g install and it worked. The only problem with running WLST scripts through Hudson builds is that doing multiple WLST scripts means opening a session with WebLogic Server and then closing that session, multiple times. This overhead is a memory hog and ultimately crashed the Hudson box. So the code/scripting is there to utilize the deployment order, but because of resource constraints, this functionality isn’t currently being used.

The following are the steps I took: 1) Installed WebLogic Server 12c to a local folder WLS_12C_MIDDLEWARE_PATH on the build server 2) Followed all steps from http://docs.oracle.com/cd/E24329_01/web.1211/e24368/maven.htm#CHEFAEBI for apache-maven-2.2.x. 3) Started the target Weblogic server 11g at (11g-IP-addr):7001 4) Edited a project pom.xml for deploying the war:

1
2
</p>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelversion>4.0.0</modelversion> <groupid>com.oracle.test</groupid> <artifactid>sample2</artifactid><packaging>war</packaging> <version>1.0-SNAPSHOT</version> <name>sample2 Maven Webapp</name> <url>http://maven.apache.org</url> <dependencies> <dependency> <groupid>junit</groupid> <artifactid>junit</artifactid> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> <build> <finalname>sample-war</finalname><plugins><plugin> <groupid>org.apache.maven.plugins</groupid> <artifactid>maven-compiler-plugin</artifactid> <configuration> <source>1.6 <target>1.6</target> </configuration> </plugin><plugin> <groupid>com.oracle.weblogic</groupid> <artifactid>wls-maven-plugin</artifactid> <version>12.1.1.0</version> <configuration> <adminurl>t3://(local-IP):7001</adminurl> <user>weblogic</user><password>weblogic1</password> <upload>true</upload> <action>deploy</action> <remote>false</remote> <verbose>true</verbose> <source>target/sample-war-10.war <name>sample-war-10</name> </configuration> <executions> <execution><phase>install</phase> <goals> <goal>deploy</goal> <goal>undeploy</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </project>

5) Ran a maven command based on the pom for deploying sample-war-10.war:

1
 mvn wls:deploy -DmiddlewareHome=(WLS_12C_MIDDLEWARE_PATH)

I had to use -DmiddlewareHome because the element in pom.xml didn’t work. 6) Created the following WLST script for changing the deployment order (changeOrder.py):

1
2
3
4
5
6
 from java.util import * from javax.management import * import javax.management.Attribute
<p>
    print 'starting the script .... '
</p>
<p>
    connect('weblogic', 'weblogic1', "t3://(11g-IP-addr):7001") edit() startEdit() cd('AppDeployments') cd('sample') set ('DeploymentOrder', 115) save() activate() disconnect() exit()

7) Then incorporated that script within the wls-maven-plugin:

1
2
3
4
5
6
7
</p>
<plugin> <groupid>com.oracle.weblogic</groupid> <artifactid>wls-maven-plugin</artifactid> <executions> <execution><phase>package</phase> <goals> <goal>wlst</goal> </goals> </execution> </executions> <configuration>  from java.util import * from javax.management import * import javax.management.Attribute
<p>
    print 'Updating deployment order .... '
</p>
<p>
    connect(System.getProperty("deploy.user"), System.getProperty("deploy.password"), System.getProperty("deploy.admin")) edit() startEdit() cd(System.getProperty("deploy.mbean")) cd(System.getProperty("deploy.library.name")) set ('DeploymentOrder', System.getProperty("deploy.order")) save() activate() disconnect()

8) Then ran the WLST call from the maven plugin:

1
 mvn wls:wlst -DfileName=changeOrder.py -DmiddlewareHome=(WLS_12C_MIDDLEWARE_PATH)

Properties are fed into the python script from Maven properties (based on a profile which is different for applications, resources, and optional packages).

This is because within the JNDI hierarchy through WLST, these assets get different Types, different versions, and different name. We can see this by logging into the server through a WLST command window and simply running an ls() command on the application or library directory. For instance, the following is an example of running the ls() command on the war. We can see that the type is AppDeployment and that the Identifier and Name are similar.

1
 wls:/sandbox/serverConfig/AppDeployments/sample-war-10> ls() dr--   SubDeployments dr--   Targets -r--   AbsoluteInstallDir                           null -r--   AbsolutePlanDir                              null -r--   AbsolutePlanPath                             null -r--   AbsoluteSourcePath                           /domains/sandbox/servers/sandboxAdminServer/upload/sample-war-10/app/sample-war.war -r--   ApplicationIdentifier                        sample-war-10 -r--   ApplicationName                              sample-war-10 -r--   CompatibilityName                            null -r--   DeploymentOrder                              102 -r--   DeploymentPlan                               null -r--   DeploymentPlanExternalDescriptors            null -r--   DeploymentPrincipalName                      null -r--   InstallDir                                   null -r--   ModuleType                                   war -r--   Name                                         sample-war-10 -r--   Notes                                        null -r--   PlanDir                                      null -r--   PlanPath                                     null -r--   SecurityDDModel                              DDOnly -r--   SourcePath                                   servers/sandboxAdminServer/upload/sample-war-10/app/sample-war.war -r--   StagingMode                                  null -r--   Type                                         AppDeployment -r--   ValidateDDSecurityData                       false -r--   VersionIdentifier                            null -r-x   freezeCurrentValue                           Void : String(attributeName) -r-x   isSet                                        Boolean : String(propertyName) -r-x   unSet                                        Void : String(propertyName)

anabolic steroids for sale

Now we will run the same command, but this time on an Optional Package, like our cxfFull that we created with Apache Shade. We can see here that the type is Library instead of AppDeployment, and that the ApplicationIdentifier includes the Manifest versions identified for this Optional Package. Therefore we need to feed in different properties when attempting to change the deployment order for an application asset as opposed to a library asset.

1
 wls:/sandbox/serverConfig/Libraries/cxfFull#2.4.5@2.4.5> ls() dr--   SubDeployments dr--   Targets -r--   AbsoluteInstallDir                           null -r--   AbsolutePlanDir                              null -r--   AbsolutePlanPath                             null -r--   AbsoluteSourcePath                           /domains/sandbox/servers/sandboxAdminServer/upload/cxfFull/2.4.5@2.4.5/app/cxf-full.jar -r--   ApplicationIdentifier                        cxfFull#2.4.5@2.4.5 -r--   ApplicationName                              cxfFull -r--   CompatibilityName                            null -r--   DeploymentOrder                              95 -r--   DeploymentPlan                               null -r--   DeploymentPlanExternalDescriptors            null -r--   DeploymentPrincipalName                      null -r--   InstallDir                                   null -r--   ModuleType                                   null -r--   Name                                         cxfFull#2.4.5@2.4.5 -r--   Notes                                        null -r--   PlanDir                                      null -r--   PlanPath                                     null -r--   SecurityDDModel                              DDOnly -r--   SourcePath                                   servers/sandboxAdminServer/upload/cxfFull/2.4.5@2.4.5/app/cxf-full.jar -r--   StagingMode                                  null -r--   Type                                         Library -r--   ValidateDDSecurityData                       false -r--   VersionIdentifier                            2.4.5@2.4.5 -r-x   freezeCurrentValue                           Void : String(attributeName) -r-x   isSet                                        Boolean : String(propertyName) -r-x   unSet                                        Void : String(propertyName)

Of course, this can be easily done through the console, but the ability to do it through the usage of the Maven Plugin can speed up the deployment process. One of the ways that we could have sped up the utilization of this plugin would be to open a WLST session, modify the deployment order of all the assets we were deploying and then closed the WLST session. Instead of trying to open, modify, close a session for each asset that was being deployed.

Top Downloaded Mp3s

Share and Enjoy