Costin Manolache wrote:
Not as major as the build breakage, I hope - but I think it is better to
do it as soon as possible.
Unless someone has good reasons not to do it, I'll start refactoring the
JMX registration. There are few things I would like to do:
- get rid of service=XXX in names. The JMX
Glenn Nielsen wrote:
I haven't looked at or played with the new JMX featuers. But I do have
some thoughts on names and scopes. We need to ensure that there is a
unique naming mechanism.
A single monitoring tool may be used to monitor multiple instances of
Tomcat. I plan on doing that some time
Glenn Nielsen wrote:
I haven't looked at or played with the new JMX featuers. But I do have
some thoughts on names and scopes. We need to ensure that there is a
unique naming mechanism.
That's the intention of the change.
A single monitoring tool may be used to monitor multiple
Thanks for clarifying that Costin. Just wanted to make sure. :-)
Costin Manolache wrote:
Glenn Nielsen wrote:
I haven't looked at or played with the new JMX featuers. But I do have
some thoughts on names and scopes. We need to ensure that there is a
unique naming mechanism.
That's the
Costin Manolache wrote:
Not as major as the build breakage, I hope - but I think it is better to
do it as soon as possible.
Unless someone has good reasons not to do it, I'll start refactoring the
JMX registration. There are few things I would like to do:
- get rid of service=XXX in names. The JMX
I forgot one important thing:
The main problem with supporting both registrations is the deregistration -
who should unregister a component ?
If the components are started by JMX - then JMX is supposed to unregister
them.
If they are created automatically - then whoever created them is
Remy Maucherat wrote:
- get rid of service=XXX in names. The JMX domain will correspond to
one tomcat instance - there is no reason to make things more complex. The
admin can just list all mbeans, search for *:type=Engine and get the
domain.
Ok, so that goes along with having only a one
