JMX Attributes can have null references. Currently a Exception is thrown because the "null-type" is not handled via objects->data:

user> (jmx/mbean "java.lang:type=GarbageCollector,name=PS MarkSweep")
{:LastGcInfo #<IllegalArgumentException java.lang.IllegalArgumentException: No implementation of method: :objects->data of protocol: #'clojure.java.jmx/Destract found for class: nil>, :CollectionCount 0, :CollectionTime 0, :MemoryPoolNames #<String[] [Ljava.lang.String;@57b8fe29>, :Name "PS MarkSweep", :Valid true, :ObjectName #<ObjectName java.lang:type=GarbageCollector,name=PS MarkSweep>}

After applying this patch:

user> (jmx/mbean "java.lang:type=GarbageCollector,name=PS MarkSweep")
{:LastGcInfo nil, :CollectionCount 0, :CollectionTime 0, :MemoryPoolNames #<String[] [Ljava.lang.String;@2225be1e>, :Name "PS MarkSweep", :Valid true, :ObjectName #<ObjectName java.lang:type=GarbageCollector,name=PS MarkSweep>}

It's handy to be able to fully override the url used by with-connection. This makes java.jmx useable when a non-rmi protocol is needed. I've attached a patch that allows specifying :url in the opts map, as well as adds some docs for the options there.

The invoke function in java.jmx won't work with overloaded mbean functions. This is because when you call invoke on an mbean operation you pass the method signature with the call. Our library always grabs the signature from the first operation with that name. If you try and invoke an overloaded method that isn't the first in the list, The parameter types/number won't match the signature that is passed and you'll get an exception.

I think perhaps the easiest/most non-intrusive solution is to add an 'invoke-with-signature' method and let the user pass in the parameter type list. I'm not exactly sure why we don't send the signature based on the parameters passed by the user anyway though. Perhaps the best solution is to just always do that.

The jmx library currently doesn't work on mbean methods that have multiple parameters with different types. This is due to the fact that into-array is used without specifying an array type. If the parameters are of different types, into-array will attempt to create an array with the type of the first parameter and fail when the second parameter is not the same.

We should just specify the array type as Object, since that is what the invoke method requires anyway.

http://download.oracle.com/javase/6/docs/api/javax/management/MBeanServerConnection.html#invoke(javax.management.ObjectName, java.lang.String, java.lang.Object[], java.lang.String[])

Currently, the only options for reading mbean attribute values are to read a single attribute or to read all attributes. It's useful to have a middle ground where a select list of attributes may be read.

The attached patch updates the raw-read function to conditionally accept a sequence of attribute names and return a map of attribute names to attribute values (the same format that the mbean function returns).

The documentation suggests that you create a JMX bean (clojure.java.jmx.Bean) by calling clojure.java.jmx/create-bean on a reference to a map whose values are the actual values you want as attributes: for instance, (create-bean (ref {:calls-so-far 0})). However, if you do this, when you get the attribute out using .getAttribute the result is the actual state value, and not the javax.management.Attribute in question as the interface specifies. This also causes a ClassCastException when you try to call .getAttributes or anything else that tries to add the attributes to an AttributeList.

The attached patch fixes this problem by wrapping the state value in a call to Attribute. so that .getAttribute yields an Attribute, and modifies objects->data to descend into Attribute values accordingly. The tests work, and it works for my use case, but I do not know whether this is the right solution in general.

In the definition of jmx/readable?, copied below, .isReadable is called.

(defn readable?
"Is attribute readable?"
[n attr]
(.isReadable (mbean-info n)))

My guess is that the intended isReadable method is from the class MBeanAttributeInfo http://docs.oracle.com/javase/1.5.0/docs/api/javax/management/MBeanAttributeInfo.html#isReadable%28%29

However, mbean-info returns an instance of class MBeanInfo. Also note that the attr argument of readable? isn't even used.