Posted on

Creating Oracle Weblogic deployment plans

Creating deployment plans

Deployment plans are part of the JSR-88 deployment standard, although not explicitly stated in this standard. A deployment plan is an XML document that defines a custom WebLogic Server deployment environment. This configuration can be used to override the specific settings defined into the application archive.

There are many reasons why you may not want to modify an application archive, one of which is testing.  For example, if you have successfully completed testing for a particular version of an application, it is desirable to keep the application archive unmodified between environments so you can have increased confidence that the application will behave the same in multiple environments as it is promoted.  Another reason might be portability.  You could have one generic JEE application archive without proprietary deployment descriptors and put all of those proprietary deployment descriptor values outside of that archive.

There are several alternatives for creating a deployment plan: start by setting your environment to include the WLS classpath:


Then, you can use the PlanGenerator utility to create a deployment plan for your application

java weblogic.PlanGenerator -all WLSDemo.ear


Generating plan for application WLSDemo.ear

Export option is: all

Exporting properties…

Saving plan to C:\wls1211_dev\user_projects\domains\base_domain\bin\plan.xml…

<8-ago-2012 11.52.48 CEST> <Info> <J2EE Deployment SPI> <BEA-260072> <Saved configuration for application, WLSDemo.ear>

Let’s check the file plan.xml which contains all the application specific settings. We will not include the whole plan.xml file here which is quite verbose; however we will include as example, how to customize some parameters contained in it.

A deployment plan is an XML file which basically defines some variables using unique names and assigns the variables values to specific elements of the custom deployment descriptors. The specific XML elements are referenced using XPath expressions.

Example: customizing the Web application root context

Open the file plan.xml file and edit it with a text editor. Next, locate the following <variable> element:



  <value xsi:nil=”true”></value>


Note that the xxxxxxxxxxxxxx will actually be an unique identifier created by the Plan Generator in order to define an unique name for the variable. In the following example, we will replace it with a meaningful name that will be referenced through the file.

Now edit the above snippet section, so that it looks like this:





Futher down in the file, locate the <variable-assignment> element which points to “weblogic-web-app/context-root” XPath expression and change the variable name to : “WeblogicWebApp_CustomContext” so that it matches with your variable:







Also notice, we have included an additional “replace” operation in it, which will obviously replace the default context with the new one (“/newcontext”).

Save the plan.xml file. What we just did is overriding the context-root element in the WebLogic Server web application deployment descriptor- weblogic.xml. The new context root is “newcontext”.

Fine, now switch to the administration console and choose to update the application from the Deployments menu.

Click the Change Path button associated with the Deployment plan path as shown:

Now select the radio button for the new plan.xml file and click Next. If necessary, use the hyperlinks next to the Current Location field to navigate to the <APP_HOME> directory.

In the next screen select the radio button “Redeploy this application using the following deployment files”. Then click Finish. Now your application should be accessible using the new web context (newcontext).

Example: customizing the JDBC modules

The first example we have covered is good starting point for creating some more customization. One real world example could be to provide a deployment plan which updates the information contained in a JDBC module that is part of your application. It is likely to happen that your application will be distributed in different environments (development/production/test) where different databases are used. For example:





In this example, if we were to change the JNDI name where the JDBC module is bound, we would need modifying the XML descriptors where the JNDI name is defined (See Chapter 7 at section “Referencing resources in the JNDI tree”).

By using a deployment plan instead, you could simply modify the value of the JDBC resources in plan.xml and update the application accordingly. Let’s see a concrete example which continues our discussion started in Chapter 7 “JNDI Portability”: in particular let’s suppose we want to change the JNDI binding of our TestEJB when porting the application in production, by changing it from “jdbc/OracleModule” to “jdbc/ProductionOracleModule”.

Start by generating a plan.xml deployment plan using the PlanGenerator utility. Now open your plan.xml and set the value element for your data source in a variable:





The above variable name (“MyDataSource_binding”) needs to be referenced in a corresponding variable-assignment stanza which sets the correct JNDI binding for your resource:



      . . . . .








What if the data source is referenced as well in Web applications, let’s say it’s injected in a Servlet? no worry! You can provide a module-override also for the Web module; in this case we will override the weblogic.xml:



       . . . .




           <xpath>/weblogic-web-app/resource-description/[res-ref-name=”jdbc/ ProductionOracleModule “]/res-ref-name</xpath>





Generating the deployment plan using the administration console

If you don’t feel like using the command line to generate the deployment plan, you can do this step using the administration console instead. Navigate to your application from the Deployments option:

Then click on your application and move to the Configuration tab. In the lower part of the screen you will be able to change the application settings such as the Context Root path. Change this value to a new context path and save.

Once you have modified some values of the configuration, the deployment plan assistant will kick in, asking you to save these changes in a deployment plan. All you have to do is providing a convenient location for the file (highly suggested to use the name plan.xml).

The next step will be customizing the plan.xml file, as we showed earlier and updating your application using that file.


Posted on

Deploying applications using the Autodeploy folder

Oracle Weblogic Auto-deployment can be useful when performing development and continuous integration tests.

When the WebLogic Server instance is running in development mode, applications and modules in the autodeploy folder are automatically deployed. The folder which is used for autodeployment is WL_HOME>/user_projects/domains/domain/autodeploy

Due to Windows’ file locking limitations, if an application is exploded, all the modules within the application must also be exploded too. In other words, you cannot use auto-deployment with an exploded application or module that contains a JAR file.

Triggering redeployment (or undeployment) of an archived application is pretty easy: just replace the archive with the new one to trigger redeployment or delete it in order to undeploy the application.

Triggering redeployment of an exploded application is a bit more complex due to OS file locking limitations. In order to trigger redeployment, you need to update the timestamp (in Unix you can just use the touchcommand) of a marker file namedREDEPLOY.

The only thing you need to pay attention is the location where WebLogic server looks for the REDEPLOY marker files: The following table will assist you:

Application type

Location of REDEPLOY file

Enterprise Application

META-INF top-level directory

Web Application

WEB-INF directory

EJB Application

META-INF top-level directory

Application Server Comparison

As for Oracle WLS, also JBoss EAP 6 by default uses a marker file to trigger redeployment of an exploded application. Just the name changes: for JBoss users it’s application-name.dodeploy and needs to be placed in the deployments folder of your standalone server.

Posted on

Deploying applications with Oracle WLS

Deploying applications with Oracle WLS can be done using a variety of instruments:

  • Using the Eclipse environment: this is the favourite option for developers, as it allows deploying applications as you are coding, using just one instrument.
  • Using the WebLogic console: this is a multi-purpose option which is recommended in case you are deploying your applications from/to a remote environment or if you don’t know the exact name or location where your deployments are.
  • Using the WLST scripting language: this option comes to your rescue in case you have to perform some batch deployments, or you want to automate your deployments while adding some logic to it. This option is discussed in the chapter 10 “Managing Oracle WLS with WLST”.
  • Using the class weblogic.Deployer: thisis, as well, a shell script solution which has been available since the very first releases of WLS. It can be still useful if you don’t need all the power of the WLST scripting language.

Deploying applications from Eclipse

Once that you have installed the OEPE, you should be able to see, in the Server Tab, the Oracle WebLogic Server icon:

Right-click on it and choose “Add or Remove” option; this will allow you delivering applications on your server.

If you want to specify the list of servers on which your application will be deployed, right-click on the application server and choose “Properties”. Expand the WebLogic | Publishing | Advanced option as depicted by the following picture:

From there, you can choose which servers will be elected as Target servers for your application. Once you are done, return to the Server icon and Right-click and choose “Publish”.