On Wed, 24 Jul 2002, Craig R. McClanahan wrote: > In general, my view is that the JSR-77 standards for managed object > names, and the corresponding attributes, are not fine grained enough to > deal with the actual manageable components in a servlet container. We're > going to need many more MBeans anyway -- it seems like a more viable > strategy would be to map the standardized names for JSR-77 purposes to the > corresponding Tomcat MBeans, but focus the Tomcat MBean architecture on > what we need to manage Tomcat.
That's pretty clear - we'll have much more than what JSR-77 specifies, but for things that are specified and as general concepts - I think it would be usefull to stay close. There are many things that will be slightly different - one example is the 'node' - which in JSR77 is the 'hostname' and we'll need 'hostname:port' ( at least ) since we support more than one instance running on a single machine. > As I've mentioned in the past, I'm also fine with looking at alternatives > to XML-based configuration formats. The *syntax* of the configuration > parameters is not very important -- the big issue is representing the > *semantics*. Can you configure every configurable property of every > component? If you can, then however you want to store it is fine. If you > can't, then it's time to go back and re-engineer the config data > persistence design. +1 > Note that valves already have MBeans today in 4.1 -- extending this to the > remaining components isn't that difficult :-). Actually all Interceptors in 3.3 ( the main branch ) and all jk components have MBeans as well ( dynamic mbeans, but still mbeans ) :-) What I'm strugling with is the naming conventions and how to map this in a configuration file ( and make this extensible to non-file based config ). > Again, this is focused on syntax. What are your thoughts on my "complete > coverage of configurable properties for all components" assertion above? I don't feel this as very hard to achieve. Maybe not random object graphs, but at least what can be expressed in JMX attributes and the relations and some object structures similar with what ant provides. If we think of all configurable components ( vavles, listeners, realms, interceptors, jkhandlers ) as mbeans - with a well-defined name and some clear attribute types - then we can express relations using refIds and we can use some simple patterns like those in ant to configure complex attributes. For example today it is difficult to define a Listener ( or Interceptor) that has some complex attributes, that would require XmlMapper rules. With ant-like patterns this become possible. It's still not absolute 'complete coverage', but I think it should reasonably satisfy your requirement. What remains hard and where XmlMapper is still the best solution is web.xml. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
