11gR1 Update and a Deployment Plan Example for WebLogic Server
By james.bayer on Jul 22, 2009
7-23-09 Update: I updated this post slightly overnight after I thought of a few additional comments, an easier approach and I took in feedback from a comment.
It is a very exciting time to be involved with Oracle Fusion Middleware. First, there are many new features and capabilities in the recently released 11gR1 that I’m learning about in training this week. My focus is mostly on WebLogic Server and surrounding technologies categorized in the Application Grid space and the SOA products. Beyond the best-of-breed qualities in the stand-alone middleware products, there is an ever-increasing amount of synergy between Oracle’s other products, both middleware and elsewhere. The number of products certified and making use of WebLogic Server is incredible. This has high value for customers in the consolidation of skill-sets and infrastructure. I am personally very impressed with the amount of innovation that has occurred in a little over a year since Oracle acquired BEA Systems, and I’m excited about what is coming in future releases. My blog folder where I store ideas for future blog entries just keeps getting more and more backlogged as I come across things worth investigating and sharing.
Deployment Plan JSR-88 Example in WebLogic Server
The Forum Question
One of the ways I gauge the increasing interest in WebLogic Server is the increasing number of posts in the WebLogic Server - General forum on OTN. Today was an especially busy day and someone inquired on a fairly straight-forward problem:
How can you do it?
Fortunately if you need to make minor configuration adjustments in application deployment descriptors (such as web.xml, weblogic.xml, application.xml, or weblogic-application.xml), but do not need to change any application code you can use a Deployment Plan (also known as JSR-88) to do this in WebLogic Server deployments. I’m not going to go into great detail here, but the essential idea is that an xml file, usually called Plan.xml that is located outside the application archive, can be used to override or set undeclared values in the deployment descriptors that are embedded in an application archive. See the image below.
Why would you ever need this?
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 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 J2EE or JEE application archive without proprietary deployment descriptors and put all of those proprietary deployment descriptor values outside of that archive. I know that WebLogic Portal code used this feature at one time to change the verbosity of a log level that was set with a Servlet initialization paramter, so you could also use this to change configuration values at runtime provided those are in a supported deployment descriptor.
Several other WebLogic bloggers have addressed Deployment Plans, so before I write about how I addressed this particular forum question, just know that you can get a general overview and more detailed examples from the following posts:
- In French – but with some screencasts - http://blog.xebia.fr/2008/04/17/les-plans-de-deploiement-weblogic/ and translated to English with Google http://bit.ly/SbQPx
A Simple Example
There is a context-root element in a web application module’s weblogic.xml file that specifies the context root of the application. When building a web application with Oracle Enterprise Pack for Eclipse, the value is automatically set to the Web Application name. Check out the WEB-INF/weblogic.xml from my Web Application named PlanWEB.
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd">
I have confirmed that my application is deployed and listening at the /PlanWEB context root on my server. How you deploy it, weblogic.Deployer, WLST, or the console is up to you. Now lets say I want to change the context root to /FooWEB at runtime, even though the weblogic.xml file in the application archive will have PlanWEB listed in the deployment descriptor.
Option 1 – The Console – The easy GUI driven way
Browse the deployment, specifically to the web module of the context root you want to change. Here’s a shot of my Deployments page after I have expanded the EAR to see it’s modules.
Home –> Deployments –> PlanEAR
Click on PlanWEB, then click the configuration tab and look at the bottom of that page. You’ll see the current context root, but not editable (depending on your console preferences it may already be editable).
- Lock and edit the console if you have not already and put in a new value like “FooWEB” and click the save button.
- The next page should prompt you for the location where the console should write the plan.xml file on the file system. Choose whatever location makes sense, but it probably makes sense to put it somewhere in the domain directory structure or some other standard or convention you come up with.
- Now activate the session. The context root should now be /FooWEB and the configuration tab of the console show now also reflect that.
Here is my plan.xml that the WebLogic Server Console generated for me.
<?xml version='1.0' encoding='UTF-8'?>
<deployment-plan xmlns="http://xmlns.oracle.com/weblogic/deployment-plan" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd">
Option 2 – weblogic.PlanGenerator – a more manual approach that could be used for automation
Here are the steps for creating the deployment plan yourself with weblogic.PlanGenerator.
- Export the EAR file to a directory – my enterprise archive name is PlanEAR.ear
- Go to your domain's bin dir with a shell and call setDomainEnv
- Call a command like this from the dir where the EAR is with the configured shell:
java weblogic.PlanGenerator -all -plan Plan.xml PlanEAR.ear
- That should generate a Plan.xml file in that directory with a bunch of stubs for values you could change at runtime in the Plan.xml file.
- Change the value of the variable for the context root. Note that the variable name is auto-generated, but it still yields a clue by the variable name prefix.
- Note that I did not use quotes for FooWEB whereas the console approach did use them. Either way seemed to work just fine.
- In order to override the context root we need to do a replace operation in the variable assignment since the element already exists in the archive. Edit Plan.xml again, this time modifying the relevant variable assignment section of the Plan.xml. Note, if the weblogic.xml did not already have the context-root explicitly listed as an xml element, then the original section could have been used.
Now we can use the weblogic.Deployer command for a redeployment with this new deployment plan Plan.xml and the EAR. We also could have used WLST.
java weblogic.Deployer -adminurl t3://localhost:7001 -user weblogic -password welcome1 -redeploy -name PlanEAR -source PlanEAR.ear -targets AdminServer -plan Plan.xml
After the command completes, I can now access the application at http://locahost:7001/FooWEB/.