My comments on mbean-names.html, and possible improvements for 5.0: The biggest problem is the representation of load-balanced tomcats. This is not covered in the current model, and it should ( even if in most cases the attribute will no be used :-)
In JSR77 terms, we need to add 'node' attributes ( and remove the comment that tomcat supports a single node, which is not true ). As mentioned in a previous thread, the User stuff will be separated, and tomcat should just have a reference to the mbean implementing UserDatabase. Same should happen for Log, assuming we get the commons-logging to support JMX and add a wrapper for JDK1.4 ( for log4j we should just use their mbean ). I assume we all agree on moving to commons-logging as API, and keeping the old Logging interface only for backward compat. The 'sequence' is a great idea - but it should be optional and maybe a simple attribute, not part of the name. Some modules are position-independent, and some only need apache-hook hints ( 'first', at-begin, at-end, last, etc ). Another issue is the ordering of the attributes - either left-to-right or reverse, but consistent ( i.e. service=, host=, path=, type=, sequence= - the name should be similar with a JNDI name, especially if we plan to support directory-based config ). I do have a big problem with the concept of 'service', even if it may be usefull in some cases I thing the 'default' should be easier. So I would propose to combine the concept of lb-group and that of service. In other words the service name will match the jk 'group' attribute. One tomcat node can be part of multiple groups, and one group may have multiple nodes. Each webapp is deployed on exactly one group. That supports ( AFAIK ) all possible use cases for lb deployment. Also related with lb, the 'node id' is very important and should be included in each name ( after 'service' ). >From 3.3 point of view ( i.e. support of 3.3 interceptors in 5.0 ) - the Listener is very close in concept and it can use the same type, while Valve and 3.3/jk Handlers are also similar. The only problem is that in 3.3 and jk we can have multiple 'chains' ( in 4.0 there is only one request-processing chain ). This will probably have to be part of the name for the other chains. Finally - I think we should try to avoid making a too strong connection between internal implementation names and JMX names. And maybe use 'tomcatType' or 'tcType' instead of 'type' - even JSR77 is avoiding type. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
