On Fri, 3 May 2002 [EMAIL PROTECTED] wrote:
> Date: Fri, 3 May 2002 09:51:51 -0700 (PDT)
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Admin webapp save-to-XML
>
>
> Ok, I don't want to start a flame war or anything - but I really
> don't like the current solution.
>
> For short term - we can live with it, and I can accept that as long
> as we are commited to replace it with something better.
>
> I spent a lot of time on this issue - there are many solutions
> around - Mozilla, gnome, KDE, linuxconf, win32 registry, etc.
>
> There one essential requirement: the manager should preserve all elements
> and config that he doesn't understand.
>
The current implementation is, AFAIK, saving 100% of what can be
recognized at startup time in server.xml, with one remaining bug (resource
definitions nested inside <DefaultContext>). This is true whether or not
the administration webapp can actually manage those resources, and
includes all custom Valves/Loggers/etc. that you might have edited in to
server.xml by hand.
What do you see that is still missing?
(NOTE: I agree with you that the admin app's capabilities are limited to
only the standard Tomcat-supplied components, but that's orthagonal to
whether or not the entire current configuration can be faithfully saved or
not.)
> The best solution IMHO is to have a layer between the config file and the
> configuration. Right now we have XmlMapper ( or however it's called now )
> pushing the config info directly into the components, and the components
> generating config fragments. That will loose information and makes the
> xml too hardcoded in.
>
In the head branch it uses commons-digester now, but functionally this is
very similar to XmlMapper -- it's a rules-based wrapper around a SAX
parser.
> In jk we have a jk_config object that reads the properties and sits
> between config changer and the components. Any change in config
> ( by wire protocol, shm, etc ) can be registered by jk_config and he
> can persist it. And it's trivial to later change the format
> and interface to the config file ( to use LDAP or registry or xml ).
>
> A similar thing can be done in java - it is obviously harder
> with XML, but it can be done. The simplest implementation would
> be to read the XML as DOM, use the DOM-SAX transformer to
> get things configured ( while preserving the DOM ), and have the
> MBeans make calls to the Config object to make the aproriate
> config changes.
>
I'm not sure that having the config data represented as a DOM tree (or a
tree of JavaBeans, or any such structure) really helps decoupling all that
much. On the way in (i.e. as Tomcat starts up), there still needs to be
some logic that understands what components must be instantiated, and
> This would eventually allow replacing the XML with an LDAP ( which
> would be nice for clustering and farming ), it would preserve
> comments and all unmanaged elements, and I believe it would be
> cleaner and easier.
>
> Just MHO.
>
> Costin
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
