Using HTTP instead of T3 for WebLogic Scripting Tool (WLST)

A friend of mine asked why the WLST connection from the Jython based scripting tool is only working with t3. IMHO using t3 for WLST is not a big deal since it is a WebLogic tool talking to WebLogic itself, and t3 was built and optimised for that.

You might want to replace t3 with HTTP anyway, e.g. for one the following reasons:

– for the sake of standards, you want to use as many standard protocols as possible. t3 is WebLogic vendor specific.

– you might have problems with t3 when connecting through firewalls.


Easy Solution

Here is the good news. Unknown to many, WLST does work with HTTP if you enable tunneling for the Admin server ( Admin Server / Protocols / General ).

Screen Shot 2015-03-02 at 10.24.50

then it’ possible to use HTTP for WLST:

Using a Network Channel

Alternatively if you want to separate the admin traffic but not use SSL (which would be enforced e.g. by using the administration port feature of WebLogic), you could create a network channel under Admin Server / Protocols / Channels for the t3 protocol, e.g. on port 8888 and enable “Tunneling” for that channel. Note that http is already enabled for the channel but this is not enough, you must enable tunneling.

Screen Shot 2015-03-02 at 10.15.29


Administration Port

The third and most secure possibility of course is using tunneling in combination with the administration port.



– You do not need the administration port for using WLST with HTTP.

– It’s not required to change WLST from t3 to HTTP. This posting only shows how it can be done if one of the reasons above apply to you.

– Changing other clients from t3 to IIOP or so, e.g. JMS clients or standalone Java clients using RMI typically has more implications which are not discussed here.



If you want to learn more about the basics WebLogic scripting tool I recommend to start with the following web cast.

New RESTful Management API in WebLogic 12.1.3

What you should know:

WebLogic 12.1.3 comes with a new implementation of the RESTful management interface.

Why RESTful?

RESTful interfaces are interesting because they …
– can be used from any language (UNIX curl, Python, Java, you name it …)
– are leight-weight. All you send is an URL using http (and possibly some JSON data)
– are leight-weight on the client side. No JVM is required, unlike let’s say JMX.
– can easily be used across firewalls because the underlying protocol is http.

What is new?

Unlike previous versions of the management interface, WebLogic 12.1.3 provides a technically better implementation for RESTful management, since the interface…
– incorperates versioning
– uses canonical URLs
– uses the well-known http verbs GET (to retrieve information. e.g about a configured data sources), POST (to create e.g. a new data source), OPTIONS (to create a JSON data structure used as a template for create a new datasource), DEL (to delete a datasource).
– returns RESTful URLs in the response.

What is missing?

Currently there is no support for JMS, Workmangers, etc. Since there is no generic way of accessing MBean attributes in WebLogic’s implementation of the RESTful management interface you have to wait for Oracle to implement support for those ressources.

Gossip is spreading that the missing ressources will be included in WebLogic 12.2.1.


more information can be found in the Oracle documentation. There are also some web casts available on the WebLogic Book Youtube channel.

Even More?

I recorded a 2 minute tech-tip for OTN. Previously I explained how the open source Jolokia alternative can be used together with WebLogic.


Simple Custom JMX MBeans with WebLogic 12c and Spring

Using the Spring framework bundled with WebLogic 12 the programming of JMX MBeans becomes as easy as writing a simple POJO within a web application. After coding the MBean as a POJO all that is left to do is creating the Spring configuration file and editing the web.xml deployment decriptor:

– Firstly you have to add the Spring <listener> to the web.xml deployment descriptor with the web.xml to get Spring started.

– Secondly create the applicationContext.xml for Spring in the WEB-INF subdirectory. Declare the Spring bean and let Spring export it to the platform MBean server.

– Thirdly deploy the web application and test it with JConsole, WLST or j4psh.

For your convinience I already built an example. You can download the deployable SimpleJMX.war file or the complete NetBeans project.

You can see the application in action, including the involved files and the deployment in the following screencast:

How to access custom MBeans from WLST is shown in the second part:

The third part is showing how to retrieve MBean attributes from a JSP:

WebLogic Scripting Tool on Capsaicin: j4psh JMX Shell with Syntax Highlighting, Wildcards and Tab-Completion

[This posting will be a part of my upcoming WebLogic 12c book]

Kudos Oracle! Over a year ago I mentioned in my Oracle Middleware and Cloud Computing book that developing WebLogic Scripting Tool (WLST) scripts with vi or Notepad++ is so 80’ies. It took you only a couple of months to respond with an Eclipse facet. Now everyone can use the bundled Eclipse with OEPE for WLST scripting . Thanks for that – even if you had it on your to-do list anyway 😉

WLST itself is a fantastic tool to interactively explore WebLogic MBean world with all their attributes, operations, and relationships (it’s described here – did I mention that this post is not for the beginners?). WLST is using its own proprietary syntax to navigate to MBeans though.

Are you willing to look beyond your own backyard? Ready to move to real MBean names? Then let’s spice it up.


j4psh JMX Shell

j4psh is a JMX shell which is using standard MBean names, provides syntax highlighting together with code completion and even wildcard patterns! In j4psh you will be using similar command as in WLST. Here is an incomplete list of the most useful commands:

  • connect, to connect to an Java EE server with the jolokia.war deployed or using the Java agent
  • pwd, to find out the current MBean name or domain
  • cd, to navigate to an MBean or domain
  • ls, to list MBean details (works with * and can be restricted as “ls -a” for attributes and “ls -o” for operations).
  • cat, to display attribute values

Unlike WLST, where every command is basically a Python method, the j4psh syntax is as easy as it gets.



For the bigger picture how j4psh can be downloaded, installed and how nicely it fits into the  Jolokia open source project see my previous posting.



In my opinion j4psh is easiest to understand when seen in action, so here are two examples of j4psh sessions.


1.) Basic usage of j4psh with WebLogic. The JMX “HelloWord”: enabling verbose garbage collection without server restart.


2.) Advanced Usage of j4psh with WebLogic: How to find the right MBean for a JDBC connection? Retrieve JMX attributes from JDBC connection pool, then use the MBean Name for the same RESTful request.


Give it a try! It’s free anyway. And let me know what you think!
And by the way, after writing about open source Jolokia, I am now determined to grow a real Jolokia plant myself…

Update: Many thanks to the Jolokia team 😉 for the plant!!

RESTful WebLogic Monitoring of Servers, Applications, JDBC and JMS with Jolokia

[This posting will be a part of my upcoming WebLogic 12c book]

This article is part II of III. Make sure you read part I explaining the basics of monitoring WebLogic with WLST, the WebLogic 12c REST-ful management API and the open source framework Jolokia.

There will be a part III in a few of days, explaining how to use j4psh with WebLogic. j4psh is a JMX shell that resembles WLST in interactive mode but includes features such as syntax highlighting and tab-completion of commands and MBean names. j4psh is highly useful to interactively find out the correct MBean names used for the requests below.

WebLogic with Jolokia

Did you ever wonder how to retrieve the configuration values for a WebLogic managed server, runtime data of a JDBC connection pool or the number of messages in a particular JMS queue with a fast and simple HTTP GET?

The examples show typical use cases for monitoring a WebLogic domain with the following configuration:

– Admin server running at localhost:7001
– Managed server with name surf1 running at localhost:7003
– JDBC datasource with the name emergencyDB and associated connection pool (target set to surf1)
– JMS configuration with a JMS server surfJMS running on managed server surf1, a module surfJMSModule containing a queue name jms/ShippingRequestQueue (target of JMS server is surf1, JMS module subdeployment set to surfJMS)
– A deployment of a web service with the name SubmitOrder and target AdminServer and surf1.

An installation of Jolokia with target set to all server of the domain is recommended to follow the examples in this part.


General: List Configuration Details of Managed Server with Name surf1

Note, that without the ?ignoreErrors=true parameter the request would fail with an “NoAccessRuntimeException” because you cannot access the SSL keystore passphrases without proper authentication. Authentication is easily possible, but beyond of the scope of this article.

Deployment: List all Deployments

Deployment: List Deployments Details for an Application with the Name SubmitOrder

JDBC Data Source: Retrieve Settings for emergencyDB Data Source with Target Managed Server surf1 Running at localhost:7003

JDBC Connection Pool: Find all JMS Servers with Target set to Managed Server Running at localhost:7003

which returns the JMS server surfJMS:

JMS: Find all JMS Servers with Target set to Managed Server Running at localhost:7003

which returns the JMS server surfJMS:

JMS: Runtime Properties for a Particular Queue

Request the MessagesCurrentCount, MessagesHighCount and MessagesReceivedCount for a queue with the name jms/ShippingRequestQueue (note the “!” is used in the URL to escape the “/” character in the queue name) in a JMS module with the name surfJMSModule (note that JMS module and queue name are typically separated in the MBean Name attribute with a “!” which has to be escaped by another “!”).

which returns the following JSON structure.

The output for the queue monitoring shows that there was a total of 3 messages sent, with a maximum of 1 in the queue (because of a deployed receiver retrieving the messages immediately) and currently 0 message in the queue.