RHQ Feature updates or bugs?

Heiko W.Rupp hrupp at redhat.com
Mon May 9 18:48:53 UTC 2011


David,

> that we (Union Pacific Railroad) register with the RHQ project and submit some of our internal research here, so as to be considered for inclusion into future releases of JON.  I am not entirely clear on the best way to submit code as I am not sure whether these constitute "bugs" or are more complicated feature requests.  Will await guidance before proceeding on these. 

We are definitively happy to have your feedback - and are also always welcoming code contributions and patches.
Please have a look at the "contributions" page on the RHQ wiki: http://rhq-project.org/display/RHQ/Contributions 
If you have questions, just ask them here - or if you want also on Irc.

> 1)  The "extensibility" of the Generic JMX plugin is a problem because some the class members are declared "private" and really should be "protected".  If they aren't obvious from the code samples we can provide, I can confer with my internal developers as to what specific class members are applicable. 

If you provide a patch against the current GIT head, we can roll it in.
> 
> 2)  Ability to attach to a local JVM's MBean server without the need for a JMX remoting.  We have written a new Generic JMX plugin that makes use of the Java Attach API to enable the RHQ agent to discover JVMs that are not exposed via JMX remoting.  These JVMs must be running under the same OS user account as the agent.  This is critical to large enterprise operations that do not want to manage hundreds or thousands of JVM JMX ports and all the security implications that entails.  This will also allow us to use JON/RHQ to manage our vast array of Stand Alone Java process.  I have code I would like to submit that demonstrates this.  The idea is that it should, most likely, be rolled into the standard Generic JMX plugin 

This may already be doable:

               /*
                 * We'll connect to the discovered VM on the local host, so set the jmx connection
                 * properties accordingly. This may only work on JDK6+, but then JDK5 is deprecated
                 * anyway.
                 */
                pluginConfiguration.put(new PropertySimple(JMXDiscoveryComponent.COMMAND_LINE_CONFIG_PROPERTY,
                        javaClazz));
                pluginConfiguration.put(new PropertySimple(JMXDiscoveryComponent.CONNECTION_TYPE,
                    LocalVMTypeDescriptor.class.getName()));

This is how I do it in the (currently very basic) hadoop plugin (see http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blob_plain;f=modules/plugins/hadoop/src/main/java/org/rhq/plugins/hadoop/HadoopServiceDiscovery.java;hb=HEAD )

> 
> 3) Expose Tomcat JNDI Datasources in the Tomcat Plugin.  This has notoriously been missing from the standard Tomcat plugin in JON 2.x and RHQ 3.x.  It exposes deployed applications but not container configured datasources.  I have a sample Tomcat datasource plugin, but I imagine it should be part of the standard Tomcat plugin. 

I agree that it would make sense to have that in the standard Tomcat plugin.

The other three issues all seem pretty valid, so definitively write a BZ about them.

And let us know if you need any help

   Heiko



More information about the rhq-devel mailing list