Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Manage your JMX-enabled applications with jManage 1.0

An introduction to jManage 1.0 using J2SE 5.0 platform MBeans as examples

By Rakesh Kalra, JavaWorld.com, 01/16/06

If you have worked with first-generation Java Management Extension consoles (like HTML Adaptor or the JBoss JMX console) in a distributed environment, you have not really seen the power of JMX client technology. Managing a clustered application by going to every application's JMX console is a highly manual and error-prone process. A distributed or clustered applications environment needs a centralized JMX console.

Then there are questions of access control: Who should be allowed to access the information exposed via MBeans (managed beans)? Who should be allowed to make changes during runtime? A clear need for fine-grained access control is prevalent. Administrators should be able to give just read-only access to development and quality assurance teams while retaining full access in the administration/operations group.

In the past, you might have used log files to figure your application's runtime behavior. Or you might have written custom management interfaces to get runtime information, perform runtime administrative operations, or for sending alerts when something goes wrong. JMX makes it easy to instrument applications using MBeans, Java objects that represent manageable resources. With MBeans, JMX-enabled applications can be managed and monitored using JMX clients.

jManage is an open source, Web and command line-based JMX client that has been built based on the real needs of production environments. It offers a centralized console for managing application clusters and distributed-application environments. The tool also provides alerts, graphs, security, SNMP (Simple Network Management Protocol) support, and fine-grained access control. jManage supports custom remoting protocols for Weblogic 6+, JBoss 3.2+, Websphere 5+, along with the standard JMX Remote API protocol (Java Specification Request (JSR) 160).

Let's first look at what J2SE 5.0 MBeans have to offer.

J2SE MBeans

With J2SE 5.0, you can now monitor the JVM via MBeans. MBeans are available for threading, memory, classloading, etc., allowing you to:

• Get thread dumps using a JMX client
• Graph your heap or nonheap memory usage
• See how garbage collection is working for you, or run GC if you like
• Turn on verbose classloading logs
• Look at configured JDK loggers and change log level without restarting the application

Now, we will set up jManage to look at these MBeans.

Setting up jManage

jManage is a Struts-based application that runs on an embedded Jetty server. You can download either jmanage-1.0.1.zip or jmanage-1.0.1.tar.gz and extract the files to a folder named jmanage-1.0.1. Please see Resources for the link to the download page. The jManage scripts are in the bin folder. If you are running in a Unix environment, you will need to make the .sh files executable by running the chmod +x *.shcommand.

If you run jManage in a secure environment (e.g., production), you should generate a key using the keygen script. Running this script also sets up the "admin" user password and writes an encrypted key in the jmanage-key file under the config folder.