Monday Jul 22, 2013

Setting up a standalone WebLogic 12c install for ADF Without a Database

One change that many folks have encountered with the 12c (12.1.2) release of WebLogic and ADF concerns the setup of stand-alone WebLogic instances extended with JRF for ADF Application deployment. 

The main problem comes when creating the JRF extended domain.  On page 6 of the config process screen you are confronted by the following:

Configure Database Screen

Note here that you need to provide information for the database that OPSS should use. 

Now this connection has a real purpose, the Oracle Platform security infrastructure for 12c needs to store it's information within a proper database so as to correctly (and supportably) manage itself across multiple servers in a cluster.  However, if like me, you just wanted to stand up a single unclustered ADF enabled WebLogic for testing deployments etc. This could be a bit of a pain, particularly in my case as the database version I'm currently running is not of the correct version.  So here I'm documenting the steps for avoiding this requirement on a single standalone server, although I stress, as far as I am aware, this is not a supported configuration for production usage.

The Steps to Install Without Needing a Database 

  1. First of all install WebLogic (wls_121200.jar) and the ADF runtime (fmw_infra_121200.jar) into the same 12c Oracle Home using their respective installers. At the end of each of the WebLogic install make sure you uncheck the Configuration Wizard launch option as we'll be doing that manually later. 
  2. Start a shell / command prompt in $MW_HOME/wlserver/common/bin
  3. Set the environment variable QS_TEMPLATES to point to $MW_HOME/wlserver/common/templates/wls/wls_jrf.jar
  4. Run and define the name of the domain that you want to create (e.g. add_domain) along with the usual WebLogic passwords and ports that you require. Finish the Quick Start wizard without starting the new domain. 
  5. Now run the conventional and on the first page choose "Update an Existing Domain" rather than "Create a new domain". The new domain (e.g. adf_domain) should now be listed for selection.
  6. On the second screen choose the templates that you wish to apply, e.g. Oracle JRF, Oracle Enterprise Manager etc.  and move on through the wizard. 
  7. On the Database Configuration Type screen this time you will see an extra option where Embedded Database (JavaDB) is offered and pre-selected. Select that and continue with the domain setup as usual with whatever managed servers you need.

Again to re-iterate this is only a setup that I would recommend for a development / testing environment and of course you should not take this approach if you're setting up any kind of clustered environment, even for testing, as the shared database has a real purpose in that case. Also consider that if your application uses MDS then you'll most likely need an database repository anyway, so again, in that instance don't use this technique.  

The fact that the normal install for the ADF Web Runtime does not offer this non-database option should be taken a a strong hint as to how supported you will be running with this configuration in a production environment.  Don't ask me for certification or support guidance, please contact Oracle Support for that information.  

Further Reading

The use of an external RDBMS Security Store for WebLogic (the configuration that  this article bypasses) is discussed in the WebLogic Documentation:

Read that chapter for a better understanding of why the default JRF install asks you to define a database connection for this purpose and why I talk about only using the technique that I've outlined here for development purposes. 

Friday Jan 06, 2012


Further to my earlier article on using the weblogic.appc command to precompile the pages in ADF applications the question came up about how to automate the same thing from Ant. 

Now in principle this should be pretty simple as the same appc command is available as an Ant task.  However, the documentation is not particularly illuminating and completely lacks any examples so you can fumble around for hours if you're a skim reader and don't pay really close attention. 

Anyway an example is worth a 1000 words. Here's the same example as last time but in Ant form.  You will still need to follow the same process for digging out the libraries that you require.


<project name="AppcTest" default="precompile" basedir=".">
  <description>Sample build file using Ant to call WLS APPC</description>

  <property name="wls_root" value="C:/builds/WLS_PS4" />
  <property name="wls_home" value="${wls_root}/wlserver_10.3" />
  <property name="adf_lib_root" value="${wls_root}/oracle_common/modules"/>
  <property name="common_lib_root" value="${wls_home}/common/deployable-libraries"/>  

  <path id="wls.classpath">
    <fileset dir="${wls_home}/server/lib">
      <include name="*.jar"/>

  <taskdef name="wlappc" classpathref="wls.classpath" 

  <target name="precompile" description="Calls WLS APPC to pre-compile an EAR">
    <wlappc source="myapp.ear" 
            classpath="${adf_lib_root}/oracle.adf.share_11.1.1/adfsharembean.jar" >
      <library file="${adf_lib_root}/oracle.adf.view_11.1.1/"/>
      <library file="${adf_lib_root}/oracle.adf.model_11.1.1/"/>
      <library file="${common_lib_root}/jstl-1.2.war"/>
      <library file="${common_lib_root}/jsf-1.2.war"/>


Thursday Dec 08, 2011

Automating Remote Deployment to Oracle WebLogic from Hudson

As part of my effort to streamline the continuous build processes around my sample and prototype portfolio, I use Hudson to trigger new builds of each sample as it is updated. Thus far I had been getting as far as testing, building (using OJDeploy), precompiling and archiving, but I'm not gotten around to deploying as part of those jobs. 

The main reason for this was due to the fact that the Hudson deployer plugin does not support WebLogic as a target (this is due in turn to a limitation of the underlying Cargo CodeHaus project) . Anyway I digress.

So rather than using the deploy step in a Hudson FreeStyle project, we need to add a normal build step at the end of the chain to handle the WebLogic deployment. Now as it happens, this is pretty easy to do, and given that you'll generally be building ADF projects with OJDeploy in any case, you have everything to hand, and no real additional setup is required. If you're not building and deploying an ADF project then the additional step you will need here is to ensure that there is a WebLogic server installation available on the Hudson machine that is executing the job.

The actual command line to trigger the deploy is pretty simple, however, at it's most basic level it takes a plain-text username and password for the WebLogic administrator.  This is probably not the kind of information that you want to leave sprinkled throughout your job configurations and console logs, so preventing that is the first step.

(Note: Even so I'm running in a pretty simple dev/test environment where the WebLogic is within the same network and I'm not using SSL, if you read the documentation references below you'll see how to beef this up for a more secure environment.)

Step 1. Conceal your Identity

The utility that we'll be using to do the deploy is weblogic.Deployer (more later, but see here for the 10.3.5 doc on this).  As I mentioned, that takes username and password parameters which we don't want, however, it also provides a way to externalize the credentials and that's what I'll use here.  This is a step that you need to carry out on the Hudson executor machine and it takes place outside of Hudson all together. We'll use the weblogic.WLST utility to generate an encrypted credential store to hold the username and password for the remote server I'm about to deploy to. You will need WebLogic or JDeveloper installed on the machine to get access to the  weblogic.Deploy and weblogic.WLST commands.  I'm signifying that location with ${WLS_HOME} here. For the sake of illustration I'm logged in as the user that runs the Hudson process and I'll store the new credential files in a sub-directory of that users home directory called wlskeys. I'm using the bash shell here:

source ${WLS_HOME}/wlserver_10.3/server/bin/
java weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands

wls:/offline> connect('weblogic','secret_admin_password',

Connecting to t3://duncan_wls:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'adf_domain'.
Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead.

wls:/adf_domain/serverConfig> storeUserConfig('~/wlskeys/',

Creating the key file can reduce the security of your system if it is not kept in a secured location after it is created.
Do you want to create the key file? y or n
The username and password that were used for this WebLogic Server connection are stored in /home/hudson/wlskeys/ and /home/hudson/wlskeys/duncan_wls_userConfig.key.

wls:/adf_domain/serverConfig> exit()
Exiting WebLogic Scripting Tool.

So there you have it. If you now peek in the specified directory you will be able to see the generated files.  It goes without saying that the files in question are ones to protect! You can go ahead and generate as many of these file pairs as you have servers for Hudson to deploy to.

Step 2. The Deploy command from Hudson 

The actual deploy step from Husdon is defined as a Execute Shell step in your job. To cut down on typing and allow for different directory structures across the Hudson slaves I'm using,  I've predefined some variables in the general Hudson config and overridden them appropriately on the slave node configuration (Node Properties -> Environment Variables):

  • ${WLS_HOME} WebLogic Home directory
  • ${WLS_KEYSTORE} The directory on which I save the properties and key files generated in Step 1 
  • ${TESTING_SERVER} The URL for the Admin Server (e.g. t3://duncan_wls:7001)

 Then the Hudson build step looks looks this:

source ${WLS_HOME}/wlserver_10.3/server/bin/
java weblogic.Deployer -adminurl ${TESTING_SERVER}
  -userconfigfile ${WLS_KEYSTORE}/
  -userkeyfile ${
  -deploy ${WORKSPACE}/deploy/myapp.ear -upload

The -upload parameter is the important one here, that will take the EAR file that Hudson has build and transfer it to the remote machine before trying the install.

Variations on the Theme

This approach is, of course, just one way of achieving this. Other options would include using the FTP-Publisher plugin to push the file to the remote server, and if this was set up to the right place and WebLogic was auto-deploying in development mode you could bypass the need for the WebLogic install on the Hudson executors. However, given that for an ADF application we really need to use OJDeploy to build the app we'll have this stuff to hand anyway. 

Other variations would include using WLST or the WebLogic ANT tasks rather than weblogic.Deploy. The end result and approach are identical in these cases.

I'm sure that the WebLogic plugin for Maven is probably an even better route to go for this entire process, however, I've not Maven-ised my main codebase yet so that will have to wait for another day.


Hawaii, Yes! 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
Follow DuncanMills on Twitter

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!


« July 2016