cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Instrumentation, anyone?
Date Thu, 04 Mar 2004 18:17:00 GMT
Gianugo Rabellino wrote:

> Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
>>> 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.

Just keep in mind that everytime you do code generation IDEs that need 
to compile classes to operate (like Eclipse or Idea) choke big time.

If we can use introspection or dynamic proxying instead, it would be a 
much better thing, IMO, for this very reason.


View raw message