JavaOne report: JMX Technology
This is the fourth installment in my summary of the sessions I
attended at JavaOne this year.
Once again, the titles here are not always the ones that appear
in the conference programme. I tried to undo the mangling that
the Trademark Police typically impose on talk titles, so let me
just state up front that Java, JMX, and JVM are trademarks of
Sun Microsystems, Inc., and any other abbreviation beginning
with J has a sporting chance of being one too.
Here are the talks summarized in this installment:
In the remaining installment, I'll cover all the other stuff
that didn't fit into any of my neat categories.
TS-5199, JMX Technology Update, Jean-François
Denise, Éamonn McManus. Hey, that's us!
(Jean-François) and I have been a double act for the last
few JavaOnes and we repeated that here. I
255, the JMX 2.0 API, much of which I have described to
death elsewhere on this blog. Jeff
Since Jeff is a bit of a poker fiend he had the idea that this
year's demo could be based on poker somehow. He found an
open-source poker server
created by students at
Universiteit Leuven. He encouraged them to create a JavaFX GUI
for the server.
Then he concocted a scenario where I was an evil poker cheater
found out through JMX instrumentation. Thanks to the Web
Services Connector, this JMX instrumentation was accessible
through the same web server that players use. Once my cheating
was discovered, the Web Services Connector also allowed Jeff to
program that would access the JMX instrumentation to detect
my cheating and kick me off.
We rehearsed this demo until nothing could go wrong, and
foresaw every possible problem. Notice the yellow cable linking
the two laptops - no way were we going to rely on the conference
centre's network to function as it should. But of course
something did go wrong. There was much less light in the room
than when we rehearsed there earlier, and I couldn't see the
keyboard with my sunglasses! Well, that was pretty minor as
problems go, and I even got an audience laugh out of it.
We were pleasantly surprised at how well received this simple
sketch was. Actual applause when I showed my cheater's hand of
four aces! We'll be thinking about another instructive demo for
next year's talk, if it's accepted.
JMX Security Options, James Gould, David Smith. This was
a very good introduction to JMX security from people who have
obviously worked closely with it. Unlike the technical
sessions, I don't think the slides from the BOFs will be
available on the JavaOne site, but if they show up on the web
somewhere I'll certainly link to them.
The message I took away from this BOF was probably different
from most attendees. Configuring JMX security is too hard. We
designed everything around standard Java security, using a
SecurityManager, policy files, and so on. But almost nobody
uses a SecurityManager, and although we also provide ways of
configuring security without one, they are either too basic or
too hard. An area for us to work on.
Manageable Java EE Applications in a Clustered
Environment, Jens Jensen, Peter Kristiansson. Jens and
Peter are at Ericsson, and I've had some contact with them
before on this subject. Peter (presenting alone) described
their solution for handling configuration in a clustered app
In their solution, each instance (JVM) has an MBeanServer that
exposes a read-only MBean view of a tree of configuration
elements. These MBeans get their data from a configuration
provider in each JVM. One of the configuration providers is the
master and the others are replicas. Updating the configuration
involves a console or other management client updating the
configuration in the master provider, which transactionally
updates the persistent store and forwards the changes to the
other providers. When a configuration provider (master or
replica) gets a change, it informs the corresponding MBean so
the MBean can send a notification.
In the next and final installment I'll cover the remainder of
the sessions I attended.