Alternatives to Spring JMX exporter in JSE/JEE without using Spring framework

Question:
Is there anything similar to the Spring JMX exporter out there WITHOUT using the Spring framework? SimpleJMX (http://256.com/sources/simplejmx/) seems to be reasonable but seems also to be a very young framework pushed only by a single person.

I'm in need of exposing a whole bunch of attributes, methods and classes as JMX but don't want to fiddle with the JMX API and writing tons of JMX interfaces. And there is no way to introduce Spring in the project (just in case you ask). Any hints or ideas are greatly appreciated :-)

Answer:
Ok, I have quickly evaluated SimpleJMX and JMXUtils. Both work as expected and are very similar to the Spring JMX exporter. However, I find JMXUtils to be more usable in my case.

With JMXUtils it is very easy to register/unregister MBeans to an already started platform mbean server. In my case I was using GlassFish V3 as application server and I didn't want to start another MBean Server just for my own mbeans.

As far as I can see the API of SimpleJMX does not allow this and you are either forced to start another MBeanServer using the SimpleJMX API and register the created mbeans (very easy with the API) or you start fiddling around with trying to register the mbeans into the platform mbean server. The later is a little bit more complicated and therefore I decided to use JMXUtils.

The downside of JMXUtils is the manipulation of the bean name. SimpleJMX uses attributes in annotations (domainName, beanName) which is very useful but with JMXUtils you have to know the syntax for naming mbeans when using mbean domains. All in all not a big deal but for my taste SimpleJMX has the better solution for this.

The bottom line is, that both libraries are great and do their job. I decided to use JMXUtils.

This question was also posted in this stackoverflow topic.

Stopping Tomcat with remote JMX enabled through script

Tomcat comes with handy start and stop scripts in the bin folder. Those scripts are working very well.
With this script it's pretty simple to start/stop Tomcat on linux systems.

But if you decide to add jmxremote properties to your start script using $JAVA_OPTS variable, stopping of Tomcat (and mostly any other AppServer started with these options) will not succeed.

There will be an error message stating that the address is already in use (BindException) and you have to kill the process manually.

The solution is very simple. Make sure the stop command does not contain the jmxremote properties definition. So you might declare a $JAVA_OPTS for the start command as usual:

 JAVA_OPTS="-Xmx256m -XX:MaxPermSize=128m 
-Dcom.sun.management.jmxremote.port=3336 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false 
-Djava.rmi.server.hostname=192.168.1.5"  

but for the stop command you must omit those jmx definitions and declare it for example like this:

 JAVA_OPTS_STOP="-Xmx256m -XX:MaxPermSize=128m"  

.
The stop command then forks a JVM with the $JAVA_OPTS_STOP definition NOT trying to open another listening socket on an already bound port.