I need to access JMX of a running process via TCP. I can't install third party utilities on the machine such as Jolokia to make JMX accessible via HTTP. Is there a library that will let Golang speak JMX or Java RMI? Has a JMX client been implemented in any non-JVM language that I can use as inspiration for a Golang port? Both read and write access would be preferable but I'll settle for read-only.
Don't know if there is a way to talk to JMX in golang without jolokia. I've done it using the golokia project which I forked and made some changes.
Here it is, hope it helps.
https://github.com/joaoh82/golokia
Related
Is it possible to create a JMX client that doesn't run on the JVM?
From my understanding JMX is a protocol on top of other protocols (like RMI) so it should be possible to create a C or Go client. Any reason why this hasn't been done?
I am aware of Jolokia and realise it can be used as a proxy.
is anyone aware of any embeddable Kerberos servers (KDC / KAdmin), which are written in Java and may run just within the JVM process (something like Hadoop minicluster or embedded LDAP servers)?
My goal it to let people run integ tests requiring Kerberos authentication without having to install local kerberos server/configure remote server and connection to it.
You can give Apache Directory Server (http://directory.apache.org/) a try. It supports LDAP and Kerberos. See this example:
http://svn.apache.org/repos/asf/directory/apacheds/trunk/kerberos-test/src/test/java/org/apache/directory/server/kerberos/kdc/SaslGssapiBindITest.java
I was/am looking for such a thing too but this is simply not really possible because you will need a fully functional DNS server for this. A fully decoupled system is necessary. You can achieve this via the virtualization-maven-plugin and a group of virtual machines in VirtualBox with an internal network.
LDAP servers won't help you at all because they do absolutely nothing with GSS-API and Kerberos. SASL does everything by delegating auth to the next available KDC.
You need KDC and DNS server. You may try Samba 4 on one machine, setup a second one which joins
the domain. Install Hadoop on it, add a third one (client), join and run tests from there.
It seems like you can have Apache DS mimic a KDC: http://directory.apache.org/apacheds/configuration/ads-2.0-configuration.html
I have a written an Embedded LDAP for similar purpose and also to you can use it for testing with Kerberos, spcially useful for cases like testing Hadoop Kerberos testing.
https://github.com/krishdey/EmbeddedLdapKDC
You may also look at the class for writing embedded JUnit testing https://github.com/krishdey/EmbeddedLdapKDC/blob/master/EmbeddedLdapKDC/src/test/java/com/krish/ead/server/KerberosLdapIntegrationTest.java
Might be useful for you.
Hadoop publishes a MiniKdc class which can be used. From the MiniKdc class doc comment:
Mini KDC based on Apache Directory Server that can be embedded in testcases or used from command line as a standalone KDC.
https://mvnrepository.com/artifact/org.apache.hadoop/hadoop-minikdc
I have a java server application that would like to provide Http
interface to for administrative tasks such as monitoring and
configuring it at run-time and such.
I have some idea that JMX would provide me with a neat standard
interface that if I implement, I would provide a nice standard
management interface that ALL types of management console applications
can use to administor my Server application.
I am wondering if Jetty has a part to play in all of this running
in-process (embedded) into my java application?
what do you think is a best way of managing/monitoring my java application using a web interface?
Appreciate your help
We added a jmx rest interface option in jetty some time ago that might be useful here.
http://webtide.intalio.com/2011/05/jetty-jmx-webservice/
It could easily be pulled from for an admin like interface for management or presentation purposes.
JMX would allow you to expose configuration points for your application. This is required if you desire a programmatic/automated way of configuring your application. Using JMX to configure application is not desirable for a naive users. It is not very likely that they would know how to use JMX. Instead a graphical console would appeal to them. They can simply see what they need to configure, refer any reference material or help and just do it.
It is desirable that you have both the options; a web console and also the JMX way for programmatic access.
Secondly, you dont need a any third party server to JMX-enable your application. You simply create an instance of MBeanServer and it will host your mbeans.
I'd like to use the Java Message Service but it says it's for the Java EE Platform. Is there a way to port it to a regular Java application (which I'm working on in Eclipse)?
JMS is part of the Java EE spec, but you can use it from any Java application. Depending on your needs, you may have to run a standalone broker, but this is just like running a regular daemon (or Windows service).
Yes, you absolutely can use JMS from a J2SE application. In fact, you can access a JMS broker from programs not written in Java at all. The ActiveMQ JMS server includes several transport connectors. The connectors allow clients to interact with ActiveMQ using different communication protocols. Most Java clients use the openwire connector. I've written a PHP client that used the STOMP protocol with great success. It consumed messages sent to a JMS Queue by a Java application running in the Tomcat Servlet Container.
This is a much more complicated question than the answer would indicate. Jms is a spec. Really just a set of interfaces. You can absolutley use those interfaces from a standalone java process. Hell you could write your own jms compliant messaging implementation. Questions you should be asking yourself is what messaging implementation will i be using and does it support jms? Even after answering that there are numerous caveats to take into account when connecting to brokers outside of a container including but not limited to transactionality, load balancing, connection pooling, and high availability. You should be very clear about what your trying to do and what messaging vendor you are working with before you can answer this completely
Many Messaging servers also provides their java api for the communication like MQ, open source Apache ActiveMQ. In that case you don't realy need to worry about JMS. You simply need to understand and use that API.
For some integration projects I would like to query JMX agents from non-Java clients.
I found two options so far, ws-jmx-connector (Soap based) and mx4j and its JMX HTTP adaptor which returns XML document responses. The JSR 262 based ws-jmx-connector seems to be no longer in active development. I have not tried MX4J so I do not know if it is possible to use the HTTP adaptor with the standard JMX implementation in the J2SE.
Are there other software projects which can help to connect non-Java clients with JMX agents, using open standard protocols?
Update: meanwhile I found this project, a "Restful JMX Adaptor". It is also described in the article RESTful Access to JMX Instrumentation, Via URI-fication of MBean Attributes
I recommend Jolokia, which is a full featured JSON/HTTP adapter for JMX. It has several client libs, i.e. jmx4perl, which allows for programatic JMX access from within perl. For Java and Javascript there are client bindings, too. More are in the pipeline (Scala, Groovy, Python). The installation is dead easy, for a Java EE container it is as simple as deploying a standard Java EE war. Other agents (OSGi, Mule, JVM6) are available, too.
Jolokia is a agent based and implies that I install a server and agents. What I am after is a lightweight pure command line, non-java based, non-agent based solution to call JMX/RMI interface.
Let it be a C-code application or perl or python whatever as long as it is fast.