DevOps tools: http REST client httpie

Doing unplanned things adds fun to our lives. Last year at Open World when heading back to the Hilton I sneaked into a REST session at Java One that I never planned to attend. Honestly, I went there to finish my very late lunch. There I learned about a REST client tool that you should add to your toolbox: http (pronounced “HTTP Pie”, with the brave abbreviation: http).

In short http is more convenient version of curl, for the non-color blind folks. It includes heaps of features, like storing session data that can referenced for following requests, easy specification of JSON values, etc.

Here is an example of its usage with the the new WebLogic 12.2.1 REST interface for administration:

http -a weblogic:welcome1 \ "localhost:7001/management/weblogic/latest/domainRuntime/serverLifeCycleRuntimes/AdminServer?links=none&fields=name,state"


Screen Shot 2016-04-15 at 09.34.54

You read it here first. But also check out my other DevOps tools postings like lsof, high CPU threads, tunnel with ngrok.


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.


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!!

Spicing up WebLogic RESTful Management with Jolokia

Management and monitoring of WebLogic resources is a day-to-day challenge for many administrators. Programming a management solution by writing JMX code in Java is a low-level and time consuming process which can be best avoided using the Jython based WebLogic scripting tool (WLST).

WLST is a higher level, domain specific language (DSL) especially developed to address management issues. A few lines of WLST code typically encapsulate hundreds of lines of Java code using JMX. Although WLST is compact and easy to write it still suffers from the “J” in JMX: Every time you execute a WLST script to monitor some attribute on the application server a JVM has to be started on the client side for WLST. This overhead can become quite substantial if you are monitoring many servers and retrieving attributes at regular intervals. In particular for monitoring systems such as Nagios (or the newer Shinken) the WLST approach is not suitable.


WebLogic 12c RESTful Management Service

One of the distinguishing new features of WebLogic 12c is its RESTful management service which can be enabled by a simple click under DOMAIN / Configuration / General / Advanced / Enable RESTful Management Services followed by a server restart.

Once enabled, you can access the most important WebLogic 12c runtime values using a simple URL syntax from your web browser or a Unix command line tool such as curl. For example you can retrieve runtime data of the administration server with fast HTTP request instead of spawning a JVM process for WLST:





WebLogic 12c RESTful management is an easy and convinient start, yet there is more possible. The open source framework Jolokia was named after of one of the the hottest chilis on the planet. Jolokia is the kind of chili that most people agree better not to eat (it’s still useful, e.g. to produce military grade tear gas and marine paint).

(Image source: courtesy of R. Huss / Jolokia)

The project is best described by the its developer:

“Jolokia is an agent based approach for remote JMX access. It is an alternative to standard JSR 160 connectors. The communication between client and agent goes over HTTP (either GET or POST), where the request and response payload is represented in JSON. The Jolokia protocol supports the following operations:

– Reading and writing JMX attributes

– Execution of JMX operations

– Searching for MBean Names by pattern

– Listing of MBean Meta-data like supported attributes, operations and notifications”


The installation process is well described at the Jolokia site. You can simply get the jolokia.war file from the Jolokia download site or the Maven central repository, nothing else is needed for WebLogic.

It’s even possible to use it without any deployment at all. Starting with JDK6 you can run it as an JVM agent, a technique typically used for profilers etc. So your java call starting WebLogic  has the following format:

java -javaagent:agent.jar ...

If you like to install the whole Jolokia project (including the JMX shell described later, the Nagios plugin, a Spring Roo addon etc)  on a UNIX system with Perl and CPAN already installed it can be as easy as:

[root@ccloud ~]# perl -MCPAN -e shell cpan shell -- CPAN exploration and modules installation (v1.9800)
cpan[1]> install JMX:Jmx4Perl
[... you have to confirm the installation of several dependencies ...]
cpan[2]> exit

After building the Jolokia module it can download the jolokia.war which is then deployed to WebLogic. In case you are playing with an admin server running in development only move it to the DOMAIN_NAME/autodeploy directory otherwise deploy it via the administration console to all servers in the domain:

oracle@ccloud [~]$ jolokia download

* Loading Jolokia meta data from
* Good PGP signature (EF101165)
* Using Jolokia 1.0.3 for Jmx4Perl 1.04
* Downloading war agent version 1.0.3 from repository
* Saved ./jolokia.war
* Good PGP signature (EF101165)

Feature Comparison: Jolokia and WebLogic 12c RESTful Management Service

Now, how does Jolokia compare to what you already have out of the box in WebLogic 12c? Here is a short overview:

WebLogic 12c
Management Service


Installation Not required:
enable from admin console
Simple installation:
deploy prebuilt jolokia.war
Availability Only for WebLogic 12c Multi vendor, multi version support:

  • WebLogic 9 to 12c
  • Most other application servers
  • Mule agent
  • JVM agent
  • OSGi agent
Approach Central
(available on admin server only)
Can be distributed
(target on every server in domain)
Access syntax Easy, proprietary URL format Standard MBean name
Return format HTML, JSON, XML JSON
Accessible Data Servers, Clusters, Deployed Apps, DataSources
Not supported: JMS
All accessable MBeans and attributes
Security Requires authentication with
admin or monitor role
Standard web based security
(can be restricted to certain IPs, roles, HTTPprotocols, etc.)
Documentation Oracle documentation Very good online documentation
Access for single attributes only
example: HeapMemoryUsage
No Yes
Access for inner path
example HeapMemoryUsage/max
No Yes
Bulk requests No Yes
(One HTTPrequest for different MBeans is translated into multiple JMX requests within WebLogic JVM and yet one result is returned)
Additional utilities JMX shell j4psh
Nagios plugin check_jmx4perl

Jolokia Request

The GET URL for a Jolokia read request has the following format:

<base-url>/read/<mbean name>/<attribute name>/<inner path>

To get started just paste the following URL into your browser or use the Unix command line utility curl (assuming you have the admin server running at localhost:7001). It will retrieve the configured ListenPort attributes:


which will return the following result for a WebLogic domain with 3 managed servers configured:

{ "request" : { "attribute" : "ListenPort",
      "mbean" : "com.bea:Type=Server,*",
      "type" : "read"
  "status" : 200,
  "timestamp" : 1334776908,
  "value" : { "com.bea:Name=AdminServer,Type=Server" : { "ListenPort" : 7001 },
      "com.bea:Name=surf1,Type=Server" : { "ListenPort" : 7003 },
      "com.bea:Name=surf2,Type=Server" : { "ListenPort" : 7005 },
      "com.bea:Name=surf3,Type=Server" : { "ListenPort" : 7007 }

Your response will be displayed in a single line. To get the format above you can past the result into one of the many online JSON formatters (or pipe the curl output to an appropriate utility).

Also I recommend to have a look at some examples about how to use Jolokia from JavaPerl and JavaScript.

Now continue reading part II of this posting with examples showing how to use Jolokia to retrieve monitoring values for servers, deployments, JDBC and JMS.

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