Serialization Vs. XML

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Serialization Vs. XML

Dain Sundstrom
The serialization Vs. XML discussion has been going for almost a week  
now and it doesn't look like we are getting sidetracked into subtle  
(yet important) points, so I'd like to take the oportunity to bring  
this up the the high level were everyone can participate.

 From my perspective I think we have the following issues and positions:

1)  Difficulty of Serialization Vs. XML:

Jeremy: Serialization is just as difficult as XML and has the same  
inherent problems when you upgrade.

Others: XMl is much easier to implement and is much easier to process  
when you upgrade.


2) If serialization is harder and more error prone then XML, is XML  
sufficient to address the configuration of geronimo.

Jeremy: Users expect the level of stability that comes from an  
application that is serializable stable.

Others: Most platforms use XML already so it must be sufficient.



I hope I have not miss represented the discussion.  This is an  
important discussion to every one involved with Geronimo, and I hope  
we can continue this discussion (at a little bit higher level) so  
that more people can participate.

-dain

Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

David Blevins
On Thu, May 19, 2005 at 04:42:18PM -0700, Dain Sundstrom wrote:
> The serialization Vs. XML discussion has been going for almost a week  
> now and it doesn't look like we are getting sidetracked into subtle  
> (yet important) points, so I'd like to take the oportunity to bring  
> this up the the high level were everyone can participate.
>

Stated this in another thread, which i don't think anyone is reading anymore.

With the proper amount of forethought and code, you can get a very limited amount of compatibility with serialization between class file versions.

Unless everyone who commits to Geronimo, Axis, ActiveMQ, Jetty, OpenEJB, Tomcat, etc. can be convinced to do that, our existing system will never be a reliable way to store configuration data across upgrades or patches.

Those are the facts.  My opinion is that it is unrealistic to expect such a high level of serialization knowledge from all committers across all our codebases.

-David
Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

David Jencks
In reply to this post by Dain Sundstrom
My first reaction is that you have seriously misrepresented everyones
positions.  However, I don't have time right now to go into much
detail, as I am still attempting to work on certification.

I have attempted to be clear all along that I fully support keeping
serialization and think that the arguments against it are way
overblown.  As such, depicting Jeremy as the sole holdout against the
tide of xml-goodness is ludicrous.

Also, my impression was that we had all agreed at the start that we
would do our best to keep xml processing out of the runtime.  I guess I
should have had everyone sign up on this since it looks like fewer
people remember this every day.

I don't know many details about object serialization.  I would like to
see a concrete demonstration of problems with serializing a reasonable
attribute value, such as a javabean or strategy object.

thanks
david jencks

On May 19, 2005, at 4:42 PM, Dain Sundstrom wrote:

> The serialization Vs. XML discussion has been going for almost a week
> now and it doesn't look like we are getting sidetracked into subtle
> (yet important) points, so I'd like to take the oportunity to bring
> this up the the high level were everyone can participate.
>
> From my perspective I think we have the following issues and positions:
>
> 1)  Difficulty of Serialization Vs. XML:
>
> Jeremy: Serialization is just as difficult as XML and has the same
> inherent problems when you upgrade.
>
> Others: XMl is much easier to implement and is much easier to process
> when you upgrade.
>
>
> 2) If serialization is harder and more error prone then XML, is XML
> sufficient to address the configuration of geronimo.
>
> Jeremy: Users expect the level of stability that comes from an
> application that is serializable stable.
>
> Others: Most platforms use XML already so it must be sufficient.
>
>
>
> I hope I have not miss represented the discussion.  This is an
> important discussion to every one involved with Geronimo, and I hope
> we can continue this discussion (at a little bit higher level) so that
> more people can participate.
>
> -dain
>

Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

David Blevins
On Thu, May 19, 2005 at 05:08:32PM -0700, David Jencks wrote:
> I have attempted to be clear all along that I fully support keeping
> serialization and think that the arguments against it are way
> overblown.  As such, depicting Jeremy as the sole holdout against the
> tide of xml-goodness is ludicrous.

I like object serialization as a sort of cache for fast startup, but don't buy into the idea that it will be a good way to patch and upgrade the server.  If serialized object data is our only way to store the current config data for an app, then users will be forced to throw all that data away and start over with a new deployment of the app on the patched server.

-David
Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

ammulder
In reply to this post by David Jencks
        And I'd like to contribute that I don't really care what the
format is so long as an end user can easily change configuration settings
-- long after the installation, and without the product running.

        To me, a text-based format is an obvious candidate for this.  
However Serialization would also be fine if there is some kind of editor
tool that meets the criteria above.  Unfortunately, no one has indicated
that they plan to develop such a tool, and it seems like a tool that lets
you edit arbitrary serialized objects is likely to present an unfriendly
user interface (though with enough attention to the objects and bean infos
this would be manageable).  That being the case, I'd lean toward an XML
format for saved configuration information to solve the configuration
issue.

        Hiram seemed to have a different perspective, which (if I am
paraphrasing correctly) is that native ActiveMQ objects can be described
using XML without requiring ActiveMQ/Geronimo glue code, while with the
current Serialization-based approach there would need to be an extensive
set of wrapper objects and stuff.  As a result I think I heard that
ActiveMQ configures itself with big blocks of XML anyway instead of taking
full advantage of Serialized objects.  While one might consider the XML to
be "glue", at least it's configuration not code.

        If I can direct a question to the Serialization supporters, I'm
not clear on why Serialization is advantageous.  It might be faster to
load than XML, but given that the quantity of XML would be fairly small
(currently all plans total about 2000 lines including comments and
whitespace), it doesn't seem like performance would be an significant
advantage.  I gather there's some objection to XMLBeans/Castor/etc. as a
core Geronimo dependency, which is reasonable (given that they're usually
large) -- but it seems like in general the XML would be "generic" enough
to be pretty tight and high-level, and therefore DOM/SAX might work fine.  
That's only speculation, of course, so I may be off base.  I also assume
Spring has configuration parsing code already (per Dain's kernel
alternative, though that's still separate from config parsing as far as I
know).  Anyway, what other benefits does Serialization offer?

        Finally, I'm sorry if we've been through some of these issues
before.  I'll be happy to take a stab at writing up whatever we eventually
conclude for the Wiki, so as not to have this discussion again next time
my memory gives out on me.  I'll be really embarrassed if I wrote it up
last time too.  :)

Aaron

On Thu, 19 May 2005, David Jencks wrote:

> My first reaction is that you have seriously misrepresented everyones
> positions.  However, I don't have time right now to go into much
> detail, as I am still attempting to work on certification.
>
> I have attempted to be clear all along that I fully support keeping
> serialization and think that the arguments against it are way
> overblown.  As such, depicting Jeremy as the sole holdout against the
> tide of xml-goodness is ludicrous.
>
> Also, my impression was that we had all agreed at the start that we
> would do our best to keep xml processing out of the runtime.  I guess I
> should have had everyone sign up on this since it looks like fewer
> people remember this every day.
>
> I don't know many details about object serialization.  I would like to
> see a concrete demonstration of problems with serializing a reasonable
> attribute value, such as a javabean or strategy object.
>
> thanks
> david jencks
>
> On May 19, 2005, at 4:42 PM, Dain Sundstrom wrote:
>
> > The serialization Vs. XML discussion has been going for almost a week
> > now and it doesn't look like we are getting sidetracked into subtle
> > (yet important) points, so I'd like to take the oportunity to bring
> > this up the the high level were everyone can participate.
> >
> > From my perspective I think we have the following issues and positions:
> >
> > 1)  Difficulty of Serialization Vs. XML:
> >
> > Jeremy: Serialization is just as difficult as XML and has the same
> > inherent problems when you upgrade.
> >
> > Others: XMl is much easier to implement and is much easier to process
> > when you upgrade.
> >
> >
> > 2) If serialization is harder and more error prone then XML, is XML
> > sufficient to address the configuration of geronimo.
> >
> > Jeremy: Users expect the level of stability that comes from an
> > application that is serializable stable.
> >
> > Others: Most platforms use XML already so it must be sufficient.
> >
> >
> >
> > I hope I have not miss represented the discussion.  This is an
> > important discussion to every one involved with Geronimo, and I hope
> > we can continue this discussion (at a little bit higher level) so that
> > more people can participate.
> >
> > -dain
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

Dain Sundstrom
In reply to this post by David Jencks
On May 19, 2005, at 5:08 PM, David Jencks wrote:

> My first reaction is that you have seriously misrepresented  
> everyones positions.  However, I don't have time right now to go  
> into much detail, as I am still attempting to work on certification.

I'm sorry, I didn't mean to misrepresent.  I have only been following  
this at a medium level, and was personally overwhelmed by the  
technical details, so this was partly for me :)

> I have attempted to be clear all along that I fully support keeping  
> serialization and think that the arguments against it are way  
> overblown.  As such, depicting Jeremy as the sole holdout against  
> the tide of xml-goodness is ludicrous.

Sorry, in the flood of emails, I forgot you were also saying we  
should keep serialization. Again sorry.

> Also, my impression was that we had all agreed at the start that we  
> would do our best to keep xml processing out of the runtime. I  
> guess I should have had everyone sign up on this since it looks  
> like fewer people remember this every day.

I am still against lots of xml processing, but I have changed my mind  
about serizlization.  I do not want to see xml tightly integrated  
into any code, I rather see a marshalling layer that converts xml to  
a nice java bean tree that represents a configuration.  That way,  
someone can start with just java code, property files, or whatever.  
I think serialization is great for caching and rpc, but I don't like  
it for long term storage or configuration information.

> I don't know many details about object serialization.  I would like  
> to see a concrete demonstration of problems with serializing a  
> reasonable attribute value, such as a javabean or strategy object.

I think that is part of the big problem here.  Too much talk not  
enough code.  I think we should get the advocates of a technique to  
show the code for class upgrade.

-dain

Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

David Jencks-2
In reply to this post by ammulder
Do you really want to be able to change all configuration settings? If
so, why?  I think this is the wrong goal.  I think there are a very few
specific config settings that should be editable after the
configuration is built, such as address and port for things that
listen.  These, however, we are probably going to want to be able to
change without manual editing of any sort.  In any case I don't think
its appropriate to allow people to edit gbean configurations directly
to change for instance the security permissions or ejb transaction
attributes.

I've been rolling an idea around in the back of my mind of having these
few "attributes" not stored in the gbean data itself but obtained from
some kind of properties gbean that gets them from a local file.  I
don't have a strong opinion on whether this is likely to work or be a
good idea.

My main objection to non-xmlbeans based xml configuration code is that
I'm reasonably sure I will get stuck maintaining it.   Based on past
experience, this is not something I want to do, ever, or ask anyone
else to do.

david jencks


On May 19, 2005, at 6:06 PM, Aaron Mulder wrote:

> And I'd like to contribute that I don't really care what the
> format is so long as an end user can easily change configuration
> settings
> -- long after the installation, and without the product running.
>
> To me, a text-based format is an obvious candidate for this.
> However Serialization would also be fine if there is some kind of
> editor
> tool that meets the criteria above.  Unfortunately, no one has
> indicated
> that they plan to develop such a tool, and it seems like a tool that
> lets
> you edit arbitrary serialized objects is likely to present an
> unfriendly
> user interface (though with enough attention to the objects and bean
> infos
> this would be manageable).  That being the case, I'd lean toward an XML
> format for saved configuration information to solve the configuration
> issue.
>
> Hiram seemed to have a different perspective, which (if I am
> paraphrasing correctly) is that native ActiveMQ objects can be
> described
> using XML without requiring ActiveMQ/Geronimo glue code, while with the
> current Serialization-based approach there would need to be an
> extensive
> set of wrapper objects and stuff.  As a result I think I heard that
> ActiveMQ configures itself with big blocks of XML anyway instead of
> taking
> full advantage of Serialized objects.  While one might consider the
> XML to
> be "glue", at least it's configuration not code.
>
> If I can direct a question to the Serialization supporters, I'm
> not clear on why Serialization is advantageous.  It might be faster to
> load than XML, but given that the quantity of XML would be fairly small
> (currently all plans total about 2000 lines including comments and
> whitespace), it doesn't seem like performance would be an significant
> advantage.  I gather there's some objection to XMLBeans/Castor/etc. as
> a
> core Geronimo dependency, which is reasonable (given that they're
> usually
> large) -- but it seems like in general the XML would be "generic"
> enough
> to be pretty tight and high-level, and therefore DOM/SAX might work
> fine.
> That's only speculation, of course, so I may be off base.  I also
> assume
> Spring has configuration parsing code already (per Dain's kernel
> alternative, though that's still separate from config parsing as far
> as I
> know).  Anyway, what other benefits does Serialization offer?
>
> Finally, I'm sorry if we've been through some of these issues
> before.  I'll be happy to take a stab at writing up whatever we
> eventually
> conclude for the Wiki, so as not to have this discussion again next
> time
> my memory gives out on me.  I'll be really embarrassed if I wrote it up
> last time too.  :)
>
> Aaron
>
> On Thu, 19 May 2005, David Jencks wrote:
>> My first reaction is that you have seriously misrepresented everyones
>> positions.  However, I don't have time right now to go into much
>> detail, as I am still attempting to work on certification.
>>
>> I have attempted to be clear all along that I fully support keeping
>> serialization and think that the arguments against it are way
>> overblown.  As such, depicting Jeremy as the sole holdout against the
>> tide of xml-goodness is ludicrous.
>>
>> Also, my impression was that we had all agreed at the start that we
>> would do our best to keep xml processing out of the runtime.  I guess
>> I
>> should have had everyone sign up on this since it looks like fewer
>> people remember this every day.
>>
>> I don't know many details about object serialization.  I would like to
>> see a concrete demonstration of problems with serializing a reasonable
>> attribute value, such as a javabean or strategy object.
>>
>> thanks
>> david jencks
>>
>> On May 19, 2005, at 4:42 PM, Dain Sundstrom wrote:
>>
>>> The serialization Vs. XML discussion has been going for almost a week
>>> now and it doesn't look like we are getting sidetracked into subtle
>>> (yet important) points, so I'd like to take the oportunity to bring
>>> this up the the high level were everyone can participate.
>>>
>>> From my perspective I think we have the following issues and
>>> positions:
>>>
>>> 1)  Difficulty of Serialization Vs. XML:
>>>
>>> Jeremy: Serialization is just as difficult as XML and has the same
>>> inherent problems when you upgrade.
>>>
>>> Others: XMl is much easier to implement and is much easier to process
>>> when you upgrade.
>>>
>>>
>>> 2) If serialization is harder and more error prone then XML, is XML
>>> sufficient to address the configuration of geronimo.
>>>
>>> Jeremy: Users expect the level of stability that comes from an
>>> application that is serializable stable.
>>>
>>> Others: Most platforms use XML already so it must be sufficient.
>>>
>>>
>>>
>>> I hope I have not miss represented the discussion.  This is an
>>> important discussion to every one involved with Geronimo, and I hope
>>> we can continue this discussion (at a little bit higher level) so
>>> that
>>> more people can participate.
>>>
>>> -dain
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

David Blevins
On Thu, May 19, 2005 at 06:04:29PM -0700, David Jencks wrote:

> Do you really want to be able to change all configuration settings? If
> so, why?  I think this is the wrong goal.  I think there are a very few
> specific config settings that should be editable after the
> configuration is built, such as address and port for things that
> listen.  These, however, we are probably going to want to be able to
> change without manual editing of any sort.  In any case I don't think
> its appropriate to allow people to edit gbean configurations directly
> to change for instance the security permissions or ejb transaction
> attributes.
>
> I've been rolling an idea around in the back of my mind of having these
> few "attributes" not stored in the gbean data itself but obtained from
> some kind of properties gbean that gets them from a local file.  I
> don't have a strong opinion on whether this is likely to work or be a
> good idea.

I certainly know what you are getting at.  Somethings users care about and somethings are just clumps of code built and handed to other objects.  You want the things users care about in nice clean buckets that are well labeled and documented.  You don't want them touching the other stuff.

The way that I've done that in the past is to have a file that basically could "override" simple values in the configuration.  Sounds like you're experimenting with something similar.

> My main objection to non-xmlbeans based xml configuration code is that
> I'm reasonably sure I will get stuck maintaining it.   Based on past
> experience, this is not something I want to do, ever, or ask anyone
> else to do.

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

-David
Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

David Jencks
In reply to this post by David Blevins
Can you find a concrete example in the current code base, excluding the
axis integration, where there is a plausible chance of such a problem?  
I don't mean to be argumentative, but just thinking I don't think of
one.  An example to look at would really help me try to consider your
point of view.

Please exclude axis :-)  I'm not very happy with the extent of
serialization in the current integration.

thanks
david jencks

On May 19, 2005, at 11:07 AM, David Blevins wrote:

> On Thu, May 19, 2005 at 05:08:32PM -0700, David Jencks wrote:
>> I have attempted to be clear all along that I fully support keeping
>> serialization and think that the arguments against it are way
>> overblown.  As such, depicting Jeremy as the sole holdout against the
>> tide of xml-goodness is ludicrous.
>
> I like object serialization as a sort of cache for fast startup, but
> don't buy into the idea that it will be a good way to patch and
> upgrade the server.  If serialized object data is our only way to
> store the current config data for an app, then users will be forced to
> throw all that data away and start over with a new deployment of the
> app on the patched server.
>
> -David
>

Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

ammulder
In reply to this post by David Blevins
On Thu, 19 May 2005, David Blevins wrote:

> > I've been rolling an idea around in the back of my mind of having these
> > few "attributes" not stored in the gbean data itself but obtained from
> > some kind of properties gbean that gets them from a local file.  I
> > don't have a strong opinion on whether this is likely to work or be a
> > good idea.
>
> > My main objection to non-xmlbeans based xml configuration code is that
> > I'm reasonably sure I will get stuck maintaining it.   Based on past
> > experience, this is not something I want to do, ever, or ask anyone
> > else to do.
>
> I kind of think that the way we use xmlbeans is the reason you are stuck maintaining it.  I think if we moved the data from xmlbeans or any other marshaller into a simple javabeans object tree, we might get more people working with the deployment code.  I'd certainly be happy to volunteer.
>
> -David
>
Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

ammulder
In reply to this post by David Jencks-2
        Ugh, sorry, ignore that last useless message.

On Thu, 19 May 2005, David Jencks wrote:
> I've been rolling an idea around in the back of my mind of having these
> few "attributes" not stored in the gbean data itself but obtained from
> some kind of properties gbean that gets them from a local file.  I
> don't have a strong opinion on whether this is likely to work or be a
> good idea.

        It's possible.  However, what about enabling/disabling SSL, AJP,
IIOP, and stuff like that?  Swapping Tomcat/Jetty?  Reconfiguring a
database pool with new pool paremeters?  Many GBeans are involved, or many
settings -- the local file would get pretty complex and extensive, I
think.

> My main objection to non-xmlbeans based xml configuration code is that
> I'm reasonably sure I will get stuck maintaining it.   Based on past
> experience, this is not something I want to do, ever, or ask anyone
> else to do.

        I've maintained a lot of SAX and DOM code in my life.  
Unfortunately my availability tends to vary over time, but I'm certainly
willing and able.

Aaron
Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

David Jencks-2

On May 19, 2005, at 6:55 PM, Aaron Mulder wrote:

> Ugh, sorry, ignore that last useless message.
>
> On Thu, 19 May 2005, David Jencks wrote:
>> I've been rolling an idea around in the back of my mind of having
>> these
>> few "attributes" not stored in the gbean data itself but obtained from
>> some kind of properties gbean that gets them from a local file.  I
>> don't have a strong opinion on whether this is likely to work or be a
>> good idea.
>
> 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.
>  Reconfiguring a
> database pool with new pool paremeters?

I'm not sure anything except "max size" should be reconfigurable.  In
any case, there aren't very  many parameters here and the ones you
might change are all numbers or strings and would fit easily in a
properties file.  Changing the security or local/xa setup should
involve a redeploy.
>   Many GBeans are involved, or many
> settings -- the local file would get pretty complex and extensive, I
> think.

I think we'd have to try it out and see.

thanks
david jencks



>
>> My main objection to non-xmlbeans based xml configuration code is that
>> I'm reasonably sure I will get stuck maintaining it.   Based on past
>> experience, this is not something I want to do, ever, or ask anyone
>> else to do.
>
> I've maintained a lot of SAX and DOM code in my life.
> Unfortunately my availability tends to vary over time, but I'm
> certainly
> willing and able.
>
> Aaron
>

Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

ammulder
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.

        I disagree.  With serialization, it's impossible to change without
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.)

        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.  :)

Aaron
Reply | Threaded
Open this post in threaded view
|

Re: Serialization Vs. XML

Bruce Snyder
On 5/19/05, Aaron Mulder <[hidden email]> 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.
>
>         I disagree.  With serialization, it's impossible to change without
> 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.)
>
>         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
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

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

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