I'd rather just add a note somewhere saying "add the mx4j jars to your classpath to enable this" than ship the jars in contrib (which doesn't get included in the binary release, anyway).
On Thu, May 6, 2010 at 7:50 AM, Gary Dusbabek <gdusba...@gmail.com> wrote: > If there is enough interest in having this in trunk, I suggest this approach: > 1) Make the CassandraDaemon.java changes, except modify it so that the > adapter will only spin up if one of the mx4j classes is found in the > classpath. > 2) Place the required mx4j jars in contrib. The license > (http://mx4j.sourceforge.net/docs/ch01s06.html) appears to be Apache > compatible. > > From an operations standpoint, I don't think that many large cluster > users (who probably already have Real Management Tools at their > disposal) will be interested in this since it adds more moving parts, > requires additional resources, etc. But from the standpoint of > small-cluster management, I see some utility in this. > > Gary. > > > On Thu, May 6, 2010 at 03:17, Ran Tavory <ran...@gmail.com> wrote: >> Thanks Gabriele, it's quite nice! >> The code change is pretty small I would even say for simplicity it's better >> to just commit that to the core. I'll paste the code below. >> In main(): >> daemon.startJmxOverHttp(); >> >> And we have: >> public void startJmxOverHttp() >> { >> try >> { >> MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); >> ObjectName processorName = new >> ObjectName("Server:name=XSLTProcessor"); >> HttpAdaptor adapter = new HttpAdaptor(9292); >> ObjectName httpName = new ObjectName("system:name=http"); >> mbs.registerMBean(adapter, httpName); >> XSLTProcessor processor = new XSLTProcessor(); >> adapter.setProcessor(processor); >> mbs.registerMBean(processor, processorName); >> adapter.start(); >> } catch(MalformedObjectNameException ex) >> { >> logger.warn("Could not start JMX over HTTP service, wrong name >> specifed in code: {}", ex); >> } catch(InstanceAlreadyExistsException ex) >> { >> logger.warn("Could not start JMX over HTTP service, already >> started: {}", ex); >> } catch(IOException ex) >> { >> logger.warn("Could not start JMX over HTTP service: {}", ex); >> } catch(JMException ex) >> { >> logger.warn("Could not start register mbean in JMX: {}", ex); >> } >> } >> That's all, now just add mx4j.jar and mx4j-tools.jar to lib and you're done. >> See screenshot for what you get from that on a live cassandra node. >> I'll try this for my installation but I think it'll be also nice to have >> that for everyone, let me know what you think. If you prefer contrib, then >> I'm not sure how to do that without having to run two processes. >> >> On Thu, May 6, 2010 at 10:15 AM, gabriele renzi <rff....@gmail.com> wrote: >>> >>> On Wed, May 5, 2010 at 12:00 PM, Ran Tavory <ran...@gmail.com> wrote: >>> > can you send it to me? I'll try to work from it. >>> >>> I updated it to trunk, moved the code into a method and added a few >>> catch'es (before: in main() throws Exception) . >>> As you can see, once exception handling and imports are removed it's >>> about ten lines. >>> >>> To compile you need the jars mx4j-tools.jar, mx4j.jar from the mx4j >>> distribution, compile, run cassandra, connect to 9292. >>> >>> I recall I've seen better looking mx4j-over-http interfaces (in e.g. >>> mule ESB) which I'd say depends on the default stylesheet, but for a >>> quick glance it kind of works. It should also be possible to only >>> expose selected beans, though I have not investigated it. >>> >>> -- >>> blog en: http://www.riffraff.info >>> blog it: http://riffraff.blogsome.com >> >> > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of Riptano, the source for professional Cassandra support http://riptano.com
