You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2002/05/03 12:49:23 UTC
Admin webapp save-to-XML
The save-to-XML feature of the admin webapp appears to be working good (of
course, I only tried the default configuration ;-) ).
I don't know what is the policy that will be used for ovewiting the existing
server.xml, but I would do:
- rename existing server.xml to server.xml.timestamp.old
- write the new one to server.xml
Is this what was planned ?
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Admin webapp save-to-XML
Posted by Amy Roh <am...@apache.org>.
Remy Maucherat wrote:
>The save-to-XML feature of the admin webapp appears to be working good (of
>course, I only tried the default configuration ;-) ).
>
>I don't know what is the policy that will be used for ovewiting the existing
>server.xml, but I would do:
>- rename existing server.xml to server.xml.timestamp.old
>- write the new one to server.xml
>
+1 :-)
Amy
>
>Is this what was planned ?
>
>Remy
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Admin webapp save-to-XML
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 6 May 2002 costinm@covalent.net wrote:
> Date: Mon, 6 May 2002 12:02:18 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: Admin webapp save-to-XML
>
> Craig,
>
> I did look at the code and I think I understand how it works.
> Save works by looking at 'getters' and generating the xml file.
> Sort of 'java bean xml persistence'.
>
Yep ... that's pretty much how it works.
> The generated file will have far more information that it needs
> ( there is no way to distinguish the 'defaults' ), it requires
> getters ( that wouldn't be a problem, but I wouldn't bet all
> components have them ), it doesn't distinguish between getters
> that refer to config and status ( i.e. runtime properties ), etc.
>
> And the biggest problem - I don't think this model can scale,
> or is flexible enough for the long term.
>
> I'm -1 on this - unless it is agreed and made clear this is just
> a temporary solution.
>
I agree with calling it a temporary solution for 4.1. Among other things,
we need mechanisms to administer and save custom component configurations
as well as the standard ones.
>
>
> > 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
>
> What's important is to have a layer between the config data ( including
> format, etc ) and the actual objects, and have all MBean setters go
> through this config layer.
>
> This is ( AFAIK - after spending a lot of time on this ) the only solution
> I could find.
>
> This will allow saving the options changed by the user ( not every
> getFoo() ), more flexibility in when is the config saved, preserve
> the structure ( including even comments ) of the XML file, etc.
>
> The way the config is read doesn't change - you can still generate
> the SAX events to drive the XMLMapper ( or just replace XmlMapper
> with walking the config and doing the calls explicitely ).,
>
> In general, I believe long term we should move toward a solution
> based on Preferences ( or JNDI ), with XML used as an import/export
> format ( or for simple standalone configurations ),
>
> ( of course, Preferences are JDK1.4 only - and we'll need a wrapper
> that works in lower versions, like commons-logging. )
>
Sounds like a reasonable long term direction.
>
> Again, this can be done post 4.1 ( and post 3.3.2 ).
>
> Costin
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Admin webapp save-to-XML
Posted by co...@covalent.net.
Craig,
I did look at the code and I think I understand how it works.
Save works by looking at 'getters' and generating the xml file.
Sort of 'java bean xml persistence'.
The generated file will have far more information that it needs
( there is no way to distinguish the 'defaults' ), it requires
getters ( that wouldn't be a problem, but I wouldn't bet all
components have them ), it doesn't distinguish between getters
that refer to config and status ( i.e. runtime properties ), etc.
And the biggest problem - I don't think this model can scale,
or is flexible enough for the long term.
I'm -1 on this - unless it is agreed and made clear this is just
a temporary solution.
> 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
What's important is to have a layer between the config data ( including
format, etc ) and the actual objects, and have all MBean setters go
through this config layer.
This is ( AFAIK - after spending a lot of time on this ) the only solution
I could find.
This will allow saving the options changed by the user ( not every
getFoo() ), more flexibility in when is the config saved, preserve
the structure ( including even comments ) of the XML file, etc.
The way the config is read doesn't change - you can still generate
the SAX events to drive the XMLMapper ( or just replace XmlMapper
with walking the config and doing the calls explicitely ).,
In general, I believe long term we should move toward a solution
based on Preferences ( or JNDI ), with XML used as an import/export
format ( or for simple standalone configurations ),
( of course, Preferences are JDK1.4 only - and we'll need a wrapper
that works in lower versions, like commons-logging. )
Again, this can be done post 4.1 ( and post 3.3.2 ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Admin webapp save-to-XML
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 3 May 2002 costinm@covalent.net wrote:
> Date: Fri, 3 May 2002 09:51:51 -0700 (PDT)
> From: costinm@covalent.net
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Admin webapp save-to-XML
Posted by co...@covalent.net.
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 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 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.
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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Admin webapp save-to-XML
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 3 May 2002, David Graff wrote:
> Date: Fri, 3 May 2002 07:52:03 -0400
> From: David Graff <ph...@mindspring.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: Admin webapp save-to-XML
>
> I'm in total agreement with that!
>
+1 ... I will implement it that way. I've been ultra-cautious about
taking this final step until trying it with a few more configurations.
> Possibly a way to roll back to a timestamp.old too?
I'm not sure how we could implement a decision to do this automatically
... obviously, a sysadmin could do it manually with no difficulty.
Craig
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: <to...@jakarta.apache.org>
> Sent: Friday, May 03, 2002 06:49
> Subject: Admin webapp save-to-XML
>
>
> > The save-to-XML feature of the admin webapp appears to be working good (of
> > course, I only tried the default configuration ;-) ).
> >
> > I don't know what is the policy that will be used for ovewiting the
> existing
> > server.xml, but I would do:
> > - rename existing server.xml to server.xml.timestamp.old
> > - write the new one to server.xml
> >
> > Is this what was planned ?
> >
> > Remy
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Admin webapp save-to-XML
Posted by David Graff <ph...@mindspring.com>.
I'm in total agreement with that!
Possibly a way to roll back to a timestamp.old too?
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: <to...@jakarta.apache.org>
Sent: Friday, May 03, 2002 06:49
Subject: Admin webapp save-to-XML
> The save-to-XML feature of the admin webapp appears to be working good (of
> course, I only tried the default configuration ;-) ).
>
> I don't know what is the policy that will be used for ovewiting the
existing
> server.xml, but I would do:
> - rename existing server.xml to server.xml.timestamp.old
> - write the new one to server.xml
>
> Is this what was planned ?
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>