geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Serialization Vs. XML
Date Fri, 20 May 2005 01:04:29 GMT
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 

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

View raw message