Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: domain of bruce.snyder@gmail.com
 designates 64.233.170.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=sW4Tt88qBxnYQa+R9YeqnGAP42vnzb0mkFMUsPSzEnF6OQusZFeDnfboKMW2FepOpEwvxCrlTxC+0mgRkk5YkrI+A7Ka1A3wmkWLeVyfdgQi2/1s4253lhBM/jm24oZSZRkWSJmScBDMDtlSsA1cvR/av3lX+Sgs2FFbxbi38iM=
Message-ID: <7b3355cb05052309015f83ae97@mail.gmail.com>
Date: Mon, 23 May 2005 10:01:58 -0600
From: Bruce Snyder <bruce.snyder@gmail.com>
Reply-To: Bruce Snyder <bruce.snyder@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: Serialization Vs. XML
In-Reply-To: <Pine.LNX.4.58.0505192253100.14605@saturn.opentools.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <CCD0F3B2-4CFA-4066-9544-1E285561D45D@iq80.com>
	 <5a98a125d5d176bdfed851274f49dd34@yahoo.com>
	 <Pine.LNX.4.58.0505192046300.14605@saturn.opentools.org>
	 <6fd29a83f256b911702d0bc84f4ac898@gluecode.com>
	 <Pine.LNX.4.58.0505192152070.14605@saturn.opentools.org>
	 <a24df0d5908d85deab1aaf7d087b4ac6@gluecode.com>
	 <Pine.LNX.4.58.0505192253100.14605@saturn.opentools.org>

On 5/19/05, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
> On Thu, 19 May 2005, David Jencks wrote:
> > >     It's possible.  However, what about enabling/disabling SSL, AJP,
> > > IIOP, and stuff like that?  Swapping Tomcat/Jetty?
> >
> > These involve changing which gbeans are present, not changing gbean
> > attribute values.  The storage format is irrelevant to this.
>=20
>         I disagree.  With serialization, it's impossible to change withou=
t
> a tool or something.  It's not like you can just "cat" in a block of
> serialized data to "config.ser".  With XML, you could just add or remove =
a
> block of data in the (I'm speculating) "config.xml" file, right?  (I'm
> assuming the configuration information is stored in roughly the same form
> as a deployment plan, which is to say, one file per configuration with
> chunks defining each active GBean in the configuration.)
>=20
>         If push comes to shove, I like WebLogic's config.xml, which has
> terse configuration for the entire server in a hierarchical XML format
> (not like a properties file with a list of ports).  If we're going to use
> external "local" files, maybe they should look like that.  I guess Tomcat
> has a similar (if more verbose) configuration strategy for server.xml.
> The problem is, any format like that would be super-tied to a J2EE
> configuration, so it might be better for a separate project that
> distributes a separately-certified J2EE-specific configuration of
> Geronimo, and not very appropriate for a generic Geronimo "this server
> might be assembled to do anything" build.  Oh, dear, I think the
> abstraction police are going to come and black out this whole paragraph.
> Never mind.  :)

Actually, Aaron, I think you have a good point. In addtion to what
David Blevins said earlier:

DB> I kind of think that the way we use xmlbeans is the reason you are
stuck maintaining it.  I think
DB> if we moved the data from xmlbeans or any other marshaller into a
simple javabeans object
DB> tree, we might get more people working with the deployment code.

I think that offering a pluggable configuration interface is the way
to go. This would allow us offer one configuration interface that
ships with Geronimo (e.g. serialization), but also to start other
subprojects offering other configuration strategies (e.g. XML,
properties files, Spring configuration, etc.). IMO, an abstraction API
will save us from having to make this decision for users, i.e. it will
allow us to offer a choice.

Bruce=20
--=20
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=3D6-E+G-N>61E<D\!G;6%I=
;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/