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 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.
- The name of the Engine will be the same as the domain: foo:type=Engine will have a name attribute with value "foo".
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 in the future. Each instance of Tomcat running needs to have a unique name.
The host name can not be used in lieu of the Engine name. I configure two Engine's which have the same host name. One for normal http, one for https.
The scoping required to ensure unique names is /Service/Engine/Host/Context.
- 2 major modes will be supported: JMX driven and API driven.
In the first mode, tomcat will be controlled using JMX. Each component
will use "preRegister" hook to learn it's name, and init() to register
itself with the parent. For example, a Valve mbean with name: domain:type=Valve,host=myHost,name=valveName
will know from the name that it must attach to host myHost in domain.
The second mode tomcat will be created the old way, by using the internal APIs. The ServerLifecycleListener will be gradually removed - each component must be in control of its naming. There are 2 cases: - components that have lifecycle ( Container, Connector ) will check in init() if they already have a name. If not - they'll do the register themself.
- all other components can be registered by the parent ( Valves, etc ).
- the big mbeans-descriptors will be split up and each package will have an mbeans-descriptors describing its own components. Modeler can auto-discover it when registerComponent() is called, and that works for everything.
I think this should be done now - or never.
The main purpose is to have smarter and more flexible components, capable to support reloading, reconfiguration and work in any environment.
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]