I'm no JMX expert at all, but I understand that basic JMX support can be easily "piggybacked" on existing code, as long as you're basically happy with monitoring and small management tasks: more important needs might require significant changes to the code base, so if I were to draw a plan I would say that we _might_ include some JMX code right now and that we _should_ plan JMX support for 2.2, even if that requires some refactoring. I have the feeling that a complex application like Cocoon really could use some management tools.
I feel your pain. Why don't you take a different direction using AOP (avoiding tangling) or even XDoclet to generate the required MBean interfaces? (I'm completly ignorant about the license of these tools, I'm just want to point that maybe put this support directly in the Cocoon code by now couldn't be a good idea.. maybe)
You have a point indeed. While AOP could be a bit too much for the current codebase, the XDoclet approach might make a lot of sense since MBeans could be built automagically at compile time. A nasty issue, actually, could be that some of the most interesting manageable stuff isn't really under Cocoon control since it belongs to Excalibur, but I feel that if we could come out with a decent XDoclet based JMX implementation even Excalibur would be happy to include it.
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Blogging at: http://www.rabellino.it/blog/)
