In this second part of the mini series we look into the problem left over from part 1.
We left the task to change the location and name of the property file we read when a configuration property is needed by the application. You my ask why we need to change the path at all. The answer is that most administrators won’t allow you to copy a file to any location on a server. They normally don’t allow access to a production server at all. You can ask them to put put the configuration file to a location of their choice and then configure this path during deployment of the application. This is exactly what we do in this blog.
In the first part we finished the sample application which read a property file from a location we can set via a context parameter in web.xml. The question now is, how to change this parameter during deployment of the application. The answer to this is to use a Deployment Plan.
Typically, deployment plans are created by developers along with the associated application files, then distributed to the administrator or another deployer, who updates the plan for a particular environment (such as staging, testing, or production). The deployment plan is stored outside of an application archive or exploded archive directory. We store the initial plan in the ViewControllers src/META-INF folder as BlogReadConfigFile_Plan.xml.
<?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"> <application-name>BlogReadConfigFile</application-name> <variable-definition> <variable> <name>ResourceFileLocation</name> <value>/tmp/readconfigfile.properties</value> </variable> </variable-definition> <module-override> <module-name>BlogReadConfigFile_BRCFViewController_webapp.war</module-name> <module-type>war</module-type> <module-descriptor external="false"> <root-element>web-app</root-element> <uri>WEB-INF/web.xml</uri> <variable-assignment> <name>ResourceFileLocation</name> <xpath>/web-app/context-param/[param-name="de.hahn.blog.readconfigfile.FILENAME"]/param-value</xpath> <operation>replace</operation> </variable-assignment> </module-descriptor> </module-override> </deployment-plan>
There are three notable parts in the plan. The first is the application name which is the same as you set under application properties in the deployment descriptor
The second section is the variable-definition section. Here we define variables which we later can use in the other parts of the descriptor as reference. Without a variable definition we can’t change a thing in the plan.
We name our variable ‘ResourceFileLocation’ and set the value to any appropriate location we like. This location don’t have to exist on the target server. We change it later anyway.
The third part is the module-overwrite where we specify which part of the of any descriptor, which is part of the deployment, we like to change.
It’s essential to name all parts exactly as they are named in the descriptors in your application.
The module name is the name of the war file we build, the type is war, as we build a war artifact. The root element describes which section of the deployed application we want to change and the URI exactly where the descriptor is located relative from its root.
The interesting part is the variable-assignment where we specify the variable name defined in the variable-definition section and which element of the defined module we want to change. This is done with a XPath expression:
which describes the location of the context parameter in web.xml with the name “de.hahn.blog.readconfigfile.FILENAME” and set it’s value to the variable value.
The operation tells what we want to do. As we want to replace the value we choose REPLACE as operation.
To make the setup complete we have to specify the BlogReadConfigFile_Plan.xml in the application properties
For more info about how to use deployment plans refer to the documentation at How to Use Deployment Plans
We can now deploy the application as usual and run the application from within JDeveloper. To show how it’s done when you deploy the application to a stand alone server we first create the ear file, then start the integrated WLS in JDevloper and open the admin console to deploy the application
which will create the ear file as we see in the log window
[06:33:59 PM] ---- Deployment started. ---- [06:33:59 PM] Target platform is (Weblogic 12.x). [06:33:59 PM] Running dependency analysis... [06:33:59 PM] Building... [06:33:59 PM] Deploying 2 profiles... [06:33:59 PM] Wrote Web Application Module to /data/development/ENTW_220.127.116.11.0/QT/BlogReadConfigFile/BRCFViewController/deploy/BlogReadConfigFile_BRCFViewController_webapp.war [06:33:59 PM] Wrote Enterprise Application Module to /data/development/ENTW_18.104.22.168.0/QT/BlogReadConfigFile/deploy/BlogReadConfigFile.ear [06:33:59 PM] Elapsed time for deployment: 1 second [06:33:59 PM] ---- Deployment finished. ----
Next step is to open the admin console and to deploy the ear file
If we run the application we see that the application tries to read the properties file in the log window
We now want to change the properties file the application is using. For this we change the location and name of the properties file we configured in the web.xml file and change the content of the properties file:
The UI has not changed, however, after you click the refresh Properties button and look into the log output you see
Please note that the location of the properties file has changed. If we had the file at the position defined in the deployment plan, the application would have read the properties from there.