<< Back to previous view

[JMX-13] Can't connect with username and password Created: 02/Oct/14  Updated: 03/Oct/14

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

Type: Defect Priority: Minor
Reporter: Janko Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm trying to connect with jmx server secured by user/password authentication:

(jmx/with-connection {:host "my.server", :port 50001 :environment {"jmx.remote.credentials" ["user" "pass"]}} (jmx/mbean "java.lang:type=OperatingSystem"))

which ends up with:

ClassNotFoundException clojure.lang.PersistentVector (no security manager: RMI class loader disabled) sun.rmi.server.LoaderHandler.loadClass (LoaderHandler.java:396)

any idea what's goin on here?



 Comments   
Comment by Janko [ 03/Oct/14 6:12 AM ]

sorry, false alarm. I've just realized I should sent :environment params as java array of Strings instead of clojure vector:

(jmx/with-connection {:host "my.server", :port 50001 :environment {"jmx.remote.credentials" (into-array String ["user" "pass"])}} (jmx/mbean "java.lang:type=OperatingSystem"))





[JMX-12] Throw exception when overloaded operation is ambiguous Created: 26/Nov/13  Updated: 20/Dec/13

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

Type: Enhancement Priority: Minor
Reporter: Stuart Sierra Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

clojure.java.jmx 0.2.0



 Description   

The clojure.java.jmx/invoke function invokes the first method it finds with a matching name, even if that method's signature does not match the type or number of arguments passed to invoke.

The correct usage is to call invoke-signature, explicitly specifying which method signature to call.

invoke could theoretically examine its arguments and guess the correct signature to call. But without that, it is better to have it throw an exception when the method overloading is ambiguous, instead of just taking the first signature.



 Comments   
Comment by Stuart Sierra [ 20/Dec/13 10:05 AM ]

This appears to be fixed already on master but not included in a release.

Comment by Stuart Sierra [ 20/Dec/13 10:17 AM ]

No, it hasn't been fixed. Commit b76f33a improves the situation but it can still occur.





[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-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-9] Eliminate several uses of reflection in java.jmx Created: 28/Oct/12  Updated: 16/Dec/12

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

Type: Enhancement Priority: Minor
Reporter: Andy Fingerhut Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File jmx-9-eliminate-reflection-v1.txt    
Patch: Code

 Description   

There are a fair number of occurrences of reflection in java.jmx that can be eliminated with the addition of suitable type hints.



 Comments   
Comment by Andy Fingerhut [ 28/Oct/12 11:56 PM ]

jmx-9-eliminate-reflection-v1.txt dated Oct 28 2012 eliminates most reflection warnings from java.jmx.

I would recommend that you check the type hints carefully before applying this, in case I messed some of them up. I am not familiar with javax.management library usage. I simply did a lot of looking at method signatures for methods used in the code in the Java library docs.

In particular, I wasn't sure whether connection should be a javax.management.MBeanServer or MBeanServerConnection. MBeanServerConnection is good enough for most of the code, but for the .registerMBean method invocation in register-mbean it needs to be a MBeanServer to avoid reflection. Perhaps it should be MBeanServer everywhere? My main question is whether that would limit the code's generality too much.

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

Well it shouldn't be MBeanServer everywhere. When using the with-connection macro connection is a RemoteMBeanServerConnection and 'registerMBean' isn't a defined method.

I'm thinking perhaps we just change register-mbean to always get the local JMX server rather than using the connection binding. You can't register mbeans with a remote jmx server.





[JMX-8] Extend java.jmx to support exposing operations in created beans Created: 31/Aug/12  Updated: 17/Jun/14

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

Type: Enhancement Priority: Major
Reporter: Chris Jeris Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Text File JMX-8.patch    
Patch: Code and Test

 Description   

The attached patch extends java.jmx to support creating beans that expose invokable operations. Operation function definitions are supplied after the state-ref in the create-bean form in a syntax similar to protocol method implementations. Type signatures, descriptions, and impact constants are harvested from metadata on the operation definitions. Nontrivial argument type binders (rest arguments, destructuring, etc) in operations are not supported.

I am sure this patch could be improved in many ways; the operation method parser in create-bean feels unnecessarily hairy and yet limited at the same time, because my macro-fu is not yet strong. The documentation examples are not yet updated, though I am happy to do this if the feature is reviewed and accepted.



 Comments   
Comment by Howard Lewis Ship [ 17/Jun/14 9:59 AM ]

I've done something similar internally, and would love to see some approach to exposing operations as an official part of the library.





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





[JMX-5] Timeout support Created: 07/Mar/12  Updated: 29/Mar/12

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

Type: Enhancement Priority: Major
Reporter: Sanel Zukan Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In the current java.jmx code there is no way to explicitly setup connection timeout when is used with-connection macro. This option can be quite useful, especially when client is trying to connect to unreliable jmx host or on location where client doesn't know jmx is enabled.

http://weblogs.java.net/blog/emcmanus/archive/2007/05/making_a_jmx_co.html can be used as starting point.



 Comments   
Comment by Nick Bailey [ 29/Mar/12 11:34 AM ]

So one way, you can set the socket timeout for jmx connections is by overriding the default rmi socket factory. See:

http://stackoverflow.com/a/1822760/940653

That solution isn't perfect though. For one thing it overrides the default factory for any rmi operation, not necessarily just jmx. It also will only work if jmx is actually falling back to the default factory. For example, if you enable jmx over SSL then the default factory won't be used and that solution won't work. What you could do though is not tell jmx to use ssl, but override the default socket factory to return ssl sockets potentially. Once again though that will be the case for an rmi operations at that point.

The solution in the post you mentioned is interesting. I kind of think adding a custom thread factory and executor service to the jmx library is a bit heavy handed. I might be more comfortable adding some documentation to the readme/wiki detailing the problem and the above possible solutions, so users can find them.

Thoughts on that approach?





[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-3] doesn't load in 1.2 Created: 17/Oct/11  Updated: 17/Oct/11  Resolved: 17/Oct/11

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

Type: Defect Priority: Major
Reporter: Kevin Downey Assignee: Unassigned
Resolution: Completed Votes: 0
Labels: None

Attachments: File jmx3.diff    
Patch: Code
Approval: Ok

 Description   

java.jmx doesn't load in clojure 1.2, the immediate problem is it uses defs with docstrings in a way supported in 1.3 but not 1.2, dunno if there is anything beyond that.



 Comments   
Comment by Kevin Downey [ 17/Oct/11 3:05 PM ]

my understanding is new contrib stuff should be compat with with 1.3 and 1.2





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





Generated at Sat Oct 25 11:08:32 CDT 2014 using JIRA 4.4#649-r158309.