Development Tools, Frameworks and more...

Basic WebLogic Deployment Plans for your ADF Application

In my recent article Dealing with ADF_FACES-30214 I alluded to the fact that you could automate the (re)setting of web.xml parameters using a deployment plan. This is particularly useful to ensure that all of those development-time switches are toggled off when deploying the application into a UAT or production environment. At this stage you could head off and just research deployment plans for WebLogic in the main WebLogic server documentation.. However, I wanted to show you how easy it is to create and use a deployment plan from within JDeveloper and to embed it into a deployment profile that can be used either from the IDE or via OJDeploy in your build system.

To help illustrate this I\ve created a simple application which echos the values of the oracle.adf.view.rich.versionString.HIDDEN and javax.faces.PROJECT_STAGE context params onto the screen using EL. This is a 12c application, however, the same approach can be taken with JDeveloper 11g as well :

So the aim here is to update those values to their production-ready settings ("true" and "Production" respectively) using a deployment plan. For convenience, I'm going to define it as part of the project contents, although strictly speaking where you put it is up to you, you'll just need to make sure that it's not packaged up inside of your deployment artifacts (e.g. the WAR file) as it's only needed at deploy time.

On the next step of the wizard you can name the new file, I've called mine dpdProductionModePlan.xml. Step through the rest of the wizard accepting the defaults. Once the wizard has run you'll find the new file in your META-INF directory. It's not too exciting:

The key task that we accomplish in a deployment plan, and the thing we actually need to do in this case, is value substitution and we can do that in a variety of deployment descriptors, including web.xml, the target here.

Logically here's what happens. The deployment plan defines one or more overrides for a particular descriptor (e.g. web.xml). It locates an element in the XML file using an XPath expression and replaces the target with the value of a named variable that is defined in the plan.

So let's start off with a variable definition, here's the variable that will be used to define the new value for PROJECT_STAGE

So that's easy enough. Now we need to locate what descriptor file to override and the XPath expression that will identify the XML change to make. Before starting this you will need to look at the deployment profile for your Web project (Project Properties > Deployment > Edit the profile you are using). Grab the name of the WAR file as defined in the profile. Here's mine for my little demo app - the WAR file is called DeploymentPlanWebapp.war:

Once we have that information we can create the override section in the plan file where we locate the correct parameter in the web.xml, and substitute in the new value:

You can see the <variable-assignment> section and the XPath expression within that which is locating the correct context-param element from the collection of parameters based on the param-name value. The param-value is then replaced with the contents of the variable we defined before.

Once the plan is complete we need to tell JDeveloper (or OJDeploy) to use it (Note that we can also use the same deployment plan when uploading an EAR file from the WebLogic console or using the web logic.Deployer task) .

To set JDeveloper up, you just need to edit your Application (EAR) deployment profile (Application > Application Properties > Deployment > Edit Your Deployment Profile), then in the general section of the deployment profile property tree you can browse for and select the plan file you've just created:

Now it's simply a matter of deploying that application using the updated profile. Here I've deployed onto my standalone 12c WebLogic installation's managed server. For completeness I've updated the plan to also replace the value for the oracle.adf.view.rich.versionString.HIDDEN value as well as the PROJECT_STAGE:

About

Duncan has been around Oracle technology way too long but occasionally has interesting things to say.
He works in the Development Tools Division at Oracle, but you guessed that right? In his spare time he contributes to the Hudson CI Server Project at Eclipse

Note that comments on this blog are moderated so (1) There may be a delay before it gets published (2) I reserve the right to ignore silly questions and comment spam is not tolerated - it gets deleted so don't even bother, we all have better things to do with our lives.However, don't be put off, I want to hear what you have to say!