Proactive insights, news and tips from Oracle WebLogic Server Support. Learn Oracle from Oracle.

  • December 21, 2017

Run Standalone WebLogic JMS Clients on Kubernetes


JMS applications are applications that use JMS services to send and receive messages. There are two main types of WebLogic JMS applications: server-side JMS applications and standalone JMS clients. Server-side applications are applications that are running on WebLogic servers or clusters and they are usually Java EE applications like MDBs, servlets and so on. Standalone JMS clients can be applications running on a foreign EE server, desktop applications, or microservices. In my last blog, Run a WebLogic JMS Sample on Kubernetes, we demonstrated WebLogic JMS communication between Java EE applications on Kubernetes and we used file-based message persistence. In this blog, we will expand the previous blog to demonstrate running standalone JMS clients communicating with each other through WebLogic JMS services, and we will use database-based message persistence.

First we create a WebLogic domain based on the sample WebLogic domain on GitHub, with an Administrator Server, and a WebLogic cluster. Then we deploy a data source, a JDBC store, and JMS resources to the WebLogic domain on a Kubernetes cluster. After the WebLogic JMS services are ready and running, we create and deploy a Java microservice to the same Kubernetes cluster to send/receive messages to/from the WebLogic JMS destinations.

We use REST API and run scripts against the Administration Server pod to deploy the resources which are targeted to the cluster.

Creating WebLogic JMS Services on Kubernetes

Preparing the WebLogic Base Domain and Data Source

If you completed the steps to create the domain, set up the MySQL database, and create the data source as described in the blog Run a WebLogic JMS Sample on Kubernetes, you can go directly to the next section. Otherwise, you need to finish the steps in the following sections of the blog Run a WebLogic JMS Sample on Kubernetes:

  1. Section "Creating the WebLogic Base Domain"
  2. Section "Setting Up and Running MySQL Server in Kubernetes"
  3. Section "Creating a Data Source for the WebLogic Server Domain"

Now you should have a WebLogic base domain running on a Kubernetes cluster and a data source which connects to a MySQL database, running in the same Kubernetes cluster.

Deploying the JMS Resources with a JDBC Store

First, prepare a JSON data file that contains definitions for one database store, one JMS server, and one JMS module. The file will be processed by a Python script to create the resources, one-by-one, using the WebLogic Server REST API.

File jms2.json:

{"resources": {  
  "jdbc1": {
    "url": "JDBCStores",
    "data": {
      "name": "jdbcStore1",
      "dataSource": [
      "targets": [{
                 "identity":["clusters", "myCluster"]
  "jms2": {
    "url": "JMSServers",
    "data": {
      "messagesThresholdHigh": -1,
      "targets": [{
                   "identity":["clusters", "myCluster"]
      "persistentStore": [
      "name": "jmsserver2"
  "module": {
    "url": "JMSSystemResources",
    "data": {
      "name": "module2",
                  "identity": [ "clusters", "myCluster" ]
  "sub2": {
    "url": "JMSSystemResources/module2/subDeployments",
    "data": {
      "name": "sub2",
                  "identity": [ "JMSServers", "jmsserver2" ]

Second, prepare the JMS module file, which contains a connection factory, a distributed queue, and a distributed topic.

File module2-jms.xml:

<?xml version='1.0' encoding='UTF-8'?>
<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms" xmlns:sec="http://xmlns.oracle.com/weblogic/security" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wls="http://xmlns.oracle.com/weblogic/security/wls" xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-jms http://xmlns.oracle.com/weblogic/weblogic-jms/1.1/weblogic-jms.xsd">
  <connection-factory name="cf2">
  <uniform-distributed-queue name="dq2">
  <uniform-distributed-topic name="dt2">

Third, copy these two files to the Administration Server pod. Then, in the Administration Server pod, run the Python script to create all the JMS resources:

$ kubectl exec $adminPod -- mkdir /u01/wlsdomain/config/jms/
$ kubectl cp ./module2-jms.xml $adminPod:/u01/wlsdomain/config/jms/
$ kubectl cp ./jms2.json $adminPod:/u01/oracle/
$ kubectl exec $adminPod -- python /u01/oracle/run.py createRes /u01/oracle/jms2.json

Launch the WebLogic Server Administration Console by going to your browser and entering the URL http://<hostIP>:30007/console in the address bar. Make sure that all the JMS resources are running successfully. Visit the monitoring page of the destination dq2 to check whether it has two members, jmsserver2@managed-server-0@dq2 and jmsserver2@managed-server-1@dq2.

Now that the WebLogic JMS services are ready, JMS messages sent to this service will be stored in the MySQL database.

Running the WebLogic JMS Client

The JMS client pod is a Java microservice which is based on the openjdk8 image packaged with the WebLogic client JAR file. The client-related scripts are on GitHub which include Dockerfile, JMS client Java files and yaml files.

NOTE: You need to get wlthint3client.jar from the installed WebLogic directory $WL_HOME/server/lib and put it in the folder jms-client/container-scripts/lib.

Step 1: Build the Docker image for JMS clients and the image will contain the compiled JMS client classes which can be run directly.

$ cd jms-client
$ docker build -t jms-client .

Step 2: Create the JMS client pod.

$ kubectl create -f jmsclient.yml

Run the Java programs to send and receive messages from the WebLogic JMS destinations. Please replace $clientPod with the actual client pod name.

Run the sender program to send messages to the destination dq2.

$ kubectl exec -it $clientPod java samples.JMSSender

By default, the sender sends 10 messages on each run and these messages are distributed to two members of dq2. Check the Administration Console to verify this.

Run the receiver program to receive messages from destination dq2.

$ kubectl exec -it $clientPod java samples.JMSReceiver dq2

The receiver uses WebLogic JMSDestinationAvailabilityHelper API to get notifications about the distributed queue's membership change, so the receiver can receive messages from both members of dq2. Please refer to the WebLogic document, "Advanced Programming with Distributed Destinations Using the JMS Destination Availability Helper API", for the detailed usage.


In this blog, we expanded our sample Run a WebLogic Sample on Kubernetes to demonstrate using external JMS clients to communicate with WebLogic JMS services running inside a Kubernetes cluster. We leveraged basic Kubernetes facilities to manage WebLogic Server life cycles and used database-based message persistence to persist data beyond the life cycle of the pods. In future blogs, we’ll explore hosting a WebLogic JMS cluster using Oracle’s upcoming fully certified WebLogic Kubernetes ‘operator-based’ Kubernetes environment. In addition, we’ll also explore using WebLogic JMS automatic service migration to migrate JMS instances from shutdown pods to running pods.


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.