Why “Through the Looking Glass”?
Until this version, jmx4r was a library which made it super easy to write simple Ruby scripts to manage Java applications using JMX.

With this version, the perspective has changed, we went through the looking glass and are now on the other side: jmx4r makes it super easy to directly manage Ruby applications by leveraging JRuby and the Java platform.

A 30-line example is worth 10,000 words:

#!/usr/bin/env jruby
require 'rubygems'
require 'jmx4r'
 
# a regular Ruby object we want to manage
class Foo < JMX::DynamicMBean
   operation "a polite management operation"
   parameter :string, "how do you want to be called?"
   returns :string
   def hello(name="world")
      "hello, #{name}!"
   end
 
   operation "double the value"
   parameter :long
   returns :long
   def double(value)
     value * 2
   end
end
 
# Java objects to register the Ruby object in the platform
import java.lang.management.ManagementFactory
import javax.management.ObjectName
 
foo = Foo.new
# each managed object needs an unique 'ObjectName'
object_name = ObjectName.new "foo:type=Foo" 
ManagementFactory.platform_mbean_server.register_mbean foo, object_name
 
# we keep the script running to manage it using jconsole
puts "open jconsole to manage foo registered under 'foo:type=Foo'"
gets
ManagementFactory.platform_mbean_server.unregister_mbean object_name

Save this script and run it using JRuby (tested it with version 1.3.0):

$  jruby bean.rb
open jconsole to manage foo registered under 'foo:type=Foo'

That’s it: you have a Ruby application which can be managed using any Java management console.

For example, if we start jconsole to manage the bean.rb script:

In the MBeans tab, we can expand Foo to see the management operation:

And we can finally invoke it (e.g. by pushing the hello or double" button) and get a result after the method is called on the Ruby object:

How to manage a Ruby object

To be manageable from a management console, the Ruby object must inherit from JMX::DynamicMBean

Since Java is statically typed, you also need to give some hints to help Java calls the Ruby object.

Each method you want to expose as a management operation must be annotated with:

• an operation (and an optional description)
• a list of parameter (with a mandatory type and optional name and description)
• a returns type

The returns and parameter type must be one of :boolean, :byte, :int, :long, :float, :double, :list, :map, :set, :string, and :void

For example, if we have a method which prints the name and age of an user, it can be minimally exposed as:

   operation
   parameter :string
   parameter :int
   returns :void
   def display(name, age)
     puts "#{name} is #{age} years old
   end

Exposing Ruby attributes for management is even simpler:

class AttributeTypesMBean < JMX::DynamicMBean
   rw_attribute :my_attr, :string, "a read/write String attribute"
   r_attribute :another_attr, :int, "a readonly int attribute"
 
    ...
  end

the rw_attribute declares a Ruby attribute (using attr_accessor) which is also exposed for management and can be read and write from a management console. Likewise, r_attribute declares a read-only Ruby attribute (using attr_reader) which can only be read from a management console.

DynamicMBean RDoc contains a description of all these annotations.

Finally, the code to register/unregister the Ruby object is taken directly from the Java library using ManagementFactory.platform_mbean_server to access the Java Platform’s MBean Server.
Each managed object must be registered with an unique ObjectName that is created using the javax.management.ObjectName class (the JMX Best Practices is a good start for an overview of JMX, the umbrella name for management in Java).

Most of this code was taken from the jmx module of jruby-extras. I fixed some issues with it but, from now on, the remaining bugs are likely written by me!

jmx4r was a simple and small library to write Ruby scripts to manage Java applications.
It is now also a simple and small library to manage Ruby applications.

With the success of JRuby and the rise of Ruby applications running on Java such as Torquebox, GitHub:fi, etc., I believe it can be very useful to leverage the features provided by the Java platform to manage Ruby applications.

As usual, to get this new release, just update the rubygem:

jruby -S gem install jmx4r

and do not hesitate to contribute:

git clone [git://github.com/jmesnil/jmx4r.git][jmx4r]

It has been a wild ride and a great team effort to release it. Onward to the final 2.0 release now!

I’ll be presenting JBoss Messaging at Irish Java Technologies Conference on January 7th & 8th 2009 at Dublin. The presentation will be mainly about JBoss Messaging 2.0 and what the team has cooked for this major release.

I am also looking forward to attend Charles Nutter’s presentations about JRuby and the versatility of Java.

See you at Dublin, the 7th & 8th January!

TangTouch and TangTouch Lite are displayed in the grey area at the top of the iPhone shell, below the last two 0 of 10,000+

[via Daniel Jalkut]

I noticed today that O’Reilly just released JRuby Cookbook. I have a few ideas I’d like to implement using JRuby and I was browsing the table of contents to check if the book could be helpful.

I was pleasantly surprised to see that it contains a section about “Performing Remote Management with JMX” using jmx4r (you can read a preview of the section by expanding it from the table of contents).

I’m obviously biased but I deeply believe that a small library such as jmx4r (less than 200 SLOC for the main file and 1/3 are comments) shows what the combination of Ruby and Java can achieve.
JRuby leverages the strong Java runtime (with its garbage collection and hotspot) and allows to access a wide range of Java libraries with all the strengths of the Ruby language.

For example, in jmx4r case, I extensively use Ruby metaprogramming toolset to dynamically create the properties and methods correponding to the MBean attributes and operations.

There are also other stories which demonstrates what JRuby brings to the table coming from the C-Ruby world.

I’m looking forward to read this cookbook and write some ruby code built on top of the Java platform.

I worked at Kelkoo for a short time in 2004-2005 after the acquisition. I made good friends and there is a bunch of smart people in this company.
I’m sure they will rebound and innovate again now that they can focus on their own core business.

Good luck to my ex-colleagues!

For the posterity, the paper prototype for TangTouch’s main view:

and the 1.0 release available from the App Store:

The Preferences paper prototype:

and the 1.0 version:

TangTouch is now available on the App Store.
It is a Tangram puzzle game for the iPhone or the iPod Touch.

I wrote this game as a way to learn more about Objective-C and Mac/iPhone development. The bulk of the application was written months ago but I waited until I had an iPhone 3G to finish it and test it in situ.

It’s a very simple game but I find it quite fun to play (being the author, it’s possible I’m biased…)

I released 2 versions:

• a commercial version with more than 200 puzzles
• a free version with 32 puzzles

This way you can download the free version with no strings attached. And if you like it, you can buy the commercial version.

Enjoy!

Learning that Apple extends NDA to rejection letters on the same day that the first phone with Google Android is launched sends a bad message to developers hesitating between the two platforms.

PC Vs Mac circa 1990, all over again? We know how it ended for Apple.

When I think about it, there is more lessons to learn from the Macintosh than the iPod to know what lies ahead of the iPhone. Apple needs developers to make a long term success of the iPhone. They provide a good SDK to create applications and the platform is really good. However, it they continue to prevent open communication (through the SDK NDA) and reject applications without a well-defined policy, they will scare a lot of developers from building on this platform and send them into Android’s arms.

Given that the reason MailWrangler was rejected is that

[The] application duplicates the functionality of the built-in iPhone application Mail without providing sufficient differentiation or added functionality, which will lead to user confusion…

and knowing that the Zawinski’s law states that

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

The inevitable conclusion is that every application will end up “duplicating the functionality of the built-in iPhone application Mail” and thus must be rejected.