On Wed, 24 Jul 2002 [EMAIL PROTECTED] wrote:
> Date: Wed, 24 Jul 2002 12:10:33 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: List Tomcat-Dev <[EMAIL PROTECTED]>
> Subject: JSR77 & tomcat5 configuration
>
> It seems JSR77 has been posted - I think everyone should read it.
>
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.
> What's important is the set of naming conventions for the managed
> objects we expose - I strongly believe that we should use those
> names wherever we provide the equivalent functionality.
>
> For example ( on what is important for me ):
> - 'node' attribute - instead of jvmRoute
> - each tomcat instance in a distributed config must know
> about all other
> - we should start exposing mbeans for JVM, WebModule and
> servlets using the naming conventions.
>
> Of course, we should keep backward compat - but all old
> attribute names should be eventually deprecated.
>
Based on the above assertion, this would be OK with me, but I don't feel
as strongly about it as Costin does.
> As I mentioned in the past, I'm not happy with XmlMapper/Digester
> style used for configuration and I'm not happy with either
> server.xml format or with the way we save the config.
>
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.
> At this moment I have a very strong belief ( and it's getting
> stronger every day ) that we should adopt a configuration
> close to the JMX model, where every configurable object
> is a named mbean.
>
> That means no more Interceptor/Context/Server/Valve/Listener/etc.
>
Note that valves already have MBeans today in 4.1 -- extending this to the
remaining components isn't that difficult :-).
> I also thing the configuration should be centered around a
> class similar with RuntimeConfigurable on ant, where all the
> user settings are stored ( including ${props} ). Any
> configuration action that involves persistence should operate
> on the RuntimeConfigurable, which should deal with saving
> the config ( in a form as close as possible to the original
> user configuration ).
>
Again, this is focused on syntax. What are your thoughts on my "complete
coverage of configurable properties for all components" assertion above?
> While I think XmlMapper/Digester are very powerfull tools, I think
> tomcat5 should follow a model that is closer to ant - i.e.
> a set of patterns and a flatter configuration file. This has proven
> to be easy and is well-understood ( even if I wrote a lot of
> code in xmlMapper, I do have troubles sometimes with it, and
> nobody can claim it's as easy as ant tasks).
>
> The question is: What do you think :-) ?
>
> Costin
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
