Gradle Weblogic Plugin

I'm pleased to announce the arrival of the Gradle Weblogic Plugin. Its been a while in the making, but I've finally got a stable version out with the 6 primary tasks. They are :

• wlDeploy - Deploys or redeploys an application or module.
• wlUndeploy - Stops the deployment unit and removes staged files from target servers.'
• wlCancel - Attempt to cancel a running deployment task.
• wlRedeploy - Redeploys a running application or part of a running application.
• wlStart - Makes a stopped (inactive) application available to clients on target servers.
• wlStop - Makes an application inactive and unavailable administration and client requests.

The latest version is currently:

You can find the source code and README at the following address:
Github - Gradle Weblogic Plugin

and the binaries are hosted at:
Bintray - Gradle Weblogic Plugin

Gradle Weblogic deployment using wldeploy

In this recipe we will see how easy it is to call the Weblogic tool "wldeploy" from Gradle.

Getting ready

The deployment depends on having a copy of the wlfullclient.jar available to the build scripts. There are plenty of tutorials online on how to create this, so I wont cover that here.

How to do it ...

• Create our build file.

• Create our Weblogic instance configurations.

How it works ...

I wont get into the configuration elements of this project. Its covered in great detail here. The important thing to take from this is we are tokenizing our build scripts making them reusable.

The deployToWLS task is where the magic happens. Here we define the ant task using the name, classname and classpath. Next we specify a directory with our deployables; I've used the "build/libs" directory as that's where my war files are packaged to. Next, through the powers of the eachFile closure we get the filename and trim the extension, we then deploy each file in that directory.

Weblogic/WLST - Packing and Unpacking a Domain

When you start working with distributed domains there will come a time when you need to pack the domain and unpack it in its distributed areas.

Whether you create your domain via the GUI or by scripting, all you're actually doing is creating a series of configuration files. At this point you're not actually starting any servers - that comes later.

Lets consider the following architecture:

AdminServer = Machine A
Managed01   = Machine B
Managed02   = Machine C
Cluster01      = Managed01, Managed02


So, you run through the wizard and configured the domain above. You should now notice your domain has been created on Machine A, but if you log into Machine B or C nothing exists. This is where the need to Pack and UnPack comes in.

To pack the domain run the following WLST script:



This script opens the domain and extracts (as a jar) the configurations required for the servers that will reside on Machines B and C. It's a skeleton configuration because the Admin server information will be excluded - a domain only ever has 1 Admin server.

Now that we have a templateName.jar we can send it to the machines that the rest of the domain will reside on and run the unpack script on each machine:




Replace the dummy properties with the ones you want for your domain and the script will do the rest. Do this for each machine then you're done. Ensure you have a Nodemanager configured on each machine then start the admin server and administer the domain as per usual.

Weblogic/WLST - Remote Control of a Domain

One of the most frustrating parts of my job is the administration of a Weblogic domain when it resides on a Linux machine. A numpty has decided that my team isn't allowed to have any permissions on Linux boxes and so we cant gain access to our Weblogic files - this means we cant stop and start our domains using startWeblogic.sh.

One solution I found was to Administer the domain via the Nodemanager.

To start, any server that you wish to administer via the Nodemanager has to be associated with a machine and a nodemanager needs to be running. Once done, start a WLST session.

 nmConnect('username','password','wl.host','nm.port','domain.name','domain.dir','socket.type')  

The command above will allow you to connect to the nodemanager.

 nmStart('server.name')  

Start the server.

 nmServerStatus('server.name')  

Get server status.

 nmKill('server.name')  

Force shutdown.

 nmDisconnect()  

Disconnect from the nodemanager.

Oracle - Query DB Sessions SQL

I had an error today when trying to create a datasource in Weblogic. The error was:

ORA-27101: shared memory realm does not exist



Cause: Unable to locate shared memory realm


Action: Verify that the realm is accessible

The cause of this error was due to the number of database sessions being outnumbered by the number of Weblogic instances. We set up 7 environments, each with 50 maximum connections but only 100 sessions on the DB side.... as you can imagine we smashed the limit.

You can check the number of sessions using:

 SELECT name, value  
  
 FROM v$parameter 
  
 WHERE name = 'sessions'  

And you can check how many are currently in use using:

 SELECT COUNT(*)  
  
 FROM v$session