<< Back to previous view

[JMX-11] Allow overriding the url used by with-connection Created: 30/Nov/12  Updated: 16/Dec/12  Resolved: 16/Dec/12

Status: Resolved
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Major
Reporter: Toby Crawley Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File with-connection-url.patch    
Patch: Code
Approval: Accepted

 Description   

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.



 Comments   
Comment by Nick Bailey [ 16/Dec/12 4:35 PM ]

Committed

https://github.com/clojure/java.jmx/commit/05bb13cde96601ddb8f9e29bcf36060060bdec99





[JMX-7] Extend Destract protocol on nil to handle Null references gracefully Created: 23/Aug/12  Updated: 26/Jul/13  Resolved: 18/Sep/12

Status: Resolved
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Major
Reporter: Jürgen Hötzel Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: bug

Attachments: Text File 0001-fix-duplicate-definition-of-test-objects-data.patch     Text File 0002-Test-Destract-protocol-on-nil-refs-JMX-7.patch     Text File 0003-Extend-Destract-protocol-on-nil-to-handle-null-refer.patch    
Patch: Code and Test
Approval: Accepted

 Description   

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



 Comments   
Comment by Nick Bailey [ 31/Aug/12 4:42 PM ]

I don't suppose you know of a standard mbean that ships with most jvms we could use to write a test case for this?

Comment by Jürgen Hötzel [ 10/Sep/12 9:21 AM ]

I don't know of a standard MBean attribute which is reproducible Null. "LastGcInfo" of "java.lang:type=GarbageCollector,name=PS MarkSweep" is non-Null after a garbage collection.

I think its better to test the Destract protocol directly instead of using a "live" MBean in this case.

BTW. there was also a duplicate definition of the existing Destract tests in test-objects->data. Patches enclosed.

Comment by Nick Bailey [ 18/Sep/12 11:20 PM ]

Committed:

https://github.com/clojure/java.jmx/commit/31b58b9c78baa9f6f31a51cd6e8b8b729af4622a





[JMX-1] java.jmx: Invoke doesn't handle overloaded mbean methods Created: 01/Sep/11  Updated: 22/Feb/12  Resolved: 22/Feb/12

Status: Resolved
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Nick Bailey Assignee: Nick Bailey
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Allow-invoking-overloaded-jmx-operations.patch    
Patch: Code
Approval: Accepted

 Description   

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.



 Comments   
Comment by Nick Bailey [ 15/Sep/11 1:46 AM ]

This patch also includes the patch I attached to JMX-2. The patch from that ticket was required to actually be able to test this functionality.

Comment by Nick Bailey [ 22/Feb/12 10:58 AM ]

Committed.





[JMX-2] java.jmx: Invoke doesn't work on methods with different parameter types. Created: 31/Aug/11  Updated: 22/Feb/12  Resolved: 22/Feb/12

Status: Resolved
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Nick Bailey Assignee: Nick Bailey
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Explictly-pass-an-Object-array-as-the-parameters-for.patch    
Patch: Code
Approval: Accepted

 Description   

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[])



 Comments   
Comment by Nick Bailey [ 22/Feb/12 11:08 AM ]

Committed.





[JMX-4] Ability to read multiple attributes in one call Created: 06/Feb/12  Updated: 23/Feb/12  Resolved: 23/Feb/12

Status: Resolved
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Enhancement Priority: Minor
Reporter: Tyler Hobbs Assignee: Nick Bailey
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Add-ability-to-read-multiple-attributes-at-once.patch     File read-attributes-001.diff    
Patch: Code and Test
Approval: Accepted

 Description   

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).



 Comments   
Comment by Nick Bailey [ 22/Feb/12 10:51 AM ]

Tyler, the attached patch doesn't apply to the HEAD of the master branch. Can you rebase and re-attach?

Comment by Nick Bailey [ 23/Feb/12 2:34 PM ]

Also, looking at the patch, the way it is currently implemented specifying multiple attributes will cause the read function to bypass the 'objects->data' transformation. We should address that as well.

Comment by Nick Bailey [ 23/Feb/12 2:36 PM ]

actually disregard that last comment, read things wrong.

Comment by Nick Bailey [ 23/Feb/12 7:22 PM ]

An updated patch that applies to the current head.

Comment by Nick Bailey [ 23/Feb/12 7:23 PM ]

Committed





[JMX-10] jmx/readable? makes incorrect call to .isReadable Created: 29/Oct/12  Updated: 26/Jul/13  Resolved: 16/Dec/12

Status: Resolved
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Andy Fingerhut Assignee: Nick Bailey
Resolution: Completed Votes: 0
Labels: None

Patch: Code and Test

 Description   

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.



 Comments   
Comment by Nick Bailey [ 16/Dec/12 5:22 PM ]

Fixed:

https://github.com/clojure/java.jmx/commit/69ebdef1881709b21bc1ae3181d41a54129f7f8f





[JMX-6] Result of clojure.java.jmx.Bean.getAttribute is not a javax.management.Attribute Created: 26/Jul/12  Updated: 26/Jul/13  Resolved: 28/Sep/12

Status: Resolved
Project: java.jmx
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Defect Priority: Minor
Reporter: Chris Jeris Assignee: Chris Jeris
Resolution: Completed Votes: 0
Labels: None

Attachments: Text File 0001-Return-a-list-of-Attribute-objects-from-.getAttribut.patch     File java-jmx-attribute-patch    
Patch: Code and Test
Approval: Accepted

 Description   

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.



 Comments   
Comment by Nick Bailey [ 06/Aug/12 4:35 PM ]

Chris,

Thanks for submitting a patch for this. I'll be able to review it sometime in the next few days hopefully.

Comment by Nick Bailey [ 31/Aug/12 4:40 PM ]

Chris,

Sorry for the delay.

Whats the reason for the addition to objects->data? By that point we've already read the attribute list for a bean and are processing the attribute values right?

Comment by Jürgen Hötzel [ 11/Sep/12 4:25 AM ]

I don't see whats wrong in the implementation of the DynamicMbean interface:

 
({:name getAttribute,                                                                                              
  :return-type java.lang.Object,                                                                                   
  :declaring-class javax.management.DynamicMBean,                                                                  
  :parameter-types [java.lang.String],                                                                             
  :exception-types                                                                                                 
  [javax.management.AttributeNotFoundException                                                                     
   javax.management.MBeanException                                                                                 
   javax.management.ReflectionException],                                                                          
  :flags #{:public :abstract}})       

the return type is

 java.lang.Object
, not
 javax.management.Attribute

Comment by Nick Bailey [ 11/Sep/12 11:14 AM ]

The documentation there is somewhat vague. Perhaps that part of the api shouldn't be changed. It seems like at least the .getAttributes implementation at least is wrong though. The documentation for AttributeList is clear that only Attribute objects should be added to the AttributeList, but it looks like all current jvm implementations (or ones we test with) don't do a good job of actually enforcing that.

http://docs.oracle.com/javase/1.5.0/docs/api/javax/management/AttributeList.html

Do we know if any built in dynamic mbeans return Attribute objects or the actual values of a specific attribute?

Comment by Nick Bailey [ 18/Sep/12 10:45 PM ]

Ok, found better documentation here.

http://docs.oracle.com/cd/E19698-01/816-7609/6mdjrf83d/index.html

So getAttribute should be returning an attributes value rather than an actual attribute object. But as I mentioned before, getAttributes should be returning a list of Attribute objects.

Comment by Nick Bailey [ 18/Sep/12 10:46 PM ]

Going to go ahead and update the patch accordingly.

Comment by Nick Bailey [ 18/Sep/12 10:59 PM ]

Updated patch. Look good Chris Jeris?

Comment by Chris Jeris [ 28/Sep/12 4:16 PM ]

Looks good and works for my use case. Sorry for the delay – I appear not to have email notifications from this JIRA configured correctly.

Comment by Nick Bailey [ 28/Sep/12 9:59 PM ]

Committed.





Generated at Sat Oct 25 01:47:24 CDT 2014 using JIRA 4.4#649-r158309.