On Mon, 6 May 2002 [EMAIL PROTECTED] wrote:
> Date: Mon, 6 May 2002 12:02:18 -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
>
> 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
