http://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JMX+AND+resolution+%3D+Unresolved+AND+assignee+is+EMPTY+ORDER+BY+priority+DESC An XML representation of a search request en-us 4.4 649 25-07-2011 http://dev.clojure.org/jira/browse/JMX-5 java.jmx <p>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.</p> <p><a href="http://weblogs.java.net/blog/emcmanus/archive/2007/05/making_a_jmx_co.html">http://weblogs.java.net/blog/emcmanus/archive/2007/05/making_a_jmx_co.html</a> can be used as starting point.</p> JMX-5

Timeout support

Enhancement Major Open Unresolved Unassigned Sanel Zukan Wed, 7 Mar 2012 05:29:59 -0600 Thu, 29 Mar 2012 11:34:17 -0500 0 1 <p>So one way, you can set the socket timeout for jmx connections is by overriding the default rmi socket factory. See:</p> <p><a href="http://stackoverflow.com/a/1822760/940653">http://stackoverflow.com/a/1822760/940653</a></p> <p>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.</p> <p>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.</p> <p>Thoughts on that approach?</p> Global Rank http://dev.clojure.org/jira/browse/JMX-8 java.jmx <p>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.</p> <p>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.</p> JMX-8

Extend java.jmx to support exposing operations in created beans

Enhancement Major Open Unresolved Unassigned Chris Jeris Fri, 31 Aug 2012 15:43:36 -0500 Fri, 31 Aug 2012 15:44:51 -0500 0 0 Global Rank Patch Code and Test http://dev.clojure.org/jira/browse/JMX-9 java.jmx <p>There are a fair number of occurrences of reflection in java.jmx that can be eliminated with the addition of suitable type hints.</p> JMX-9

Eliminate several uses of reflection in java.jmx

Enhancement Minor Open Unresolved Unassigned Andy Fingerhut Sun, 28 Oct 2012 23:49:16 -0500 Sun, 16 Dec 2012 17:07:31 -0600 0 0 <p>jmx-9-eliminate-reflection-v1.txt dated Oct 28 2012 eliminates most reflection warnings from java.jmx.</p> <p>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.</p> <p>In particular, I wasn't sure whether <b>connection</b> 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.</p> <p>Well it shouldn't be MBeanServer everywhere. When using the with-connection macro <b>connection</b> is a RemoteMBeanServerConnection and 'registerMBean' isn't a defined method. </p> <p>I'm thinking perhaps we just change register-mbean to always get the local JMX server rather than using the <b>connection</b> binding. You can't register mbeans with a remote jmx server.</p> Global Rank Patch Code