geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: New Feature: XML based configurations
Date Wed, 05 Apr 2006 03:46:37 GMT
Dain,

I'm building as we speak :)

Sweet

Matt

Dain Sundstrom wrote:
> I have just committed to branch 1.1 optional support for using  xstream 
> to save configurations in our repository.  XStream is a  wonderful 
> library at codehaus which is a replacement for Java Object  
> Serialization.  As it's name implies, instead of create unreadable  
> binary data link Java Object Serialization, XStream creates a very  nice 
> xml document.  A basic FAQ follow:
> 
> 
> o How to I enable this optional feature?
> 
> Build the server with the following command:
> 
> $ maven - 
> Dorg.apache.geronimo.kernel.config.Marshaler=org.apache.geronimo.kernel. 
> config.xstream.XStreamConfigurationMarshaler new
> 
> This will cause the build system to create a server containing xml  
> based configs instead of serializaed data.  Once the server is built,  
> use the following command to start the server:
> 
> $ java - 
> Dorg.apache.geronimo.kernel.config.Marshaler=org.apache.geronimo.kernel. 
> config.xstream.XStreamConfigurationMarshaler -jar assemblies/j2ee- 
> jetty-server/target/geronimo-1.1-SNAPSHOT/bin/server.jar --long
> 
> 
> o Where are the xml configs?
> 
> The file name of the saved configurations has not changed and are  still 
> located at META-INF/config.ser
> 
> 
> o Where is the schema for this file?
> 
> As is noted in the saved file, the format of this file is  undocumented 
> and will change without notice.  The file is very  readable and should 
> be easy to hack, but you should not do this  unless absolutely necessary.
> 
> 
> o Why is this useful if I'm not supposed to change the file?
> 
> The file will be very useful while debugging deployment problems  since 
> is readable (expect to see many emails requesting a config.ser  file be 
> emailed to a dev).  Also, in the case of an emergency repair  to a 
> production system, you can now easily crack open any  configuration and 
> start hacking (be careful).
> 
> By far the most important impact of this feature is that is should  
> vastly reduce the serialization related problems in the server.   
> XStream is much more accepting of changes in classes and will even  save 
> classes that don't implement java.io.Serializable.  This will  allow us 
> to patch jars and classes in an existing server and work  with libraries 
> that don't properly implement java.io.Serializable.
> 
> 
> o Why isn't this on by default? Why don't we get rid of the  
> serialization based code?
> 
> I would like to do both of these before we ship 1.1, but I wanted to  
> give everyone a chance to checkout the code.  Also, this code could  
> have weird unforeseen side-effects in the TCK so until we are passing  
> the TCK, I don't want to touch anything.
> 
> 
> o Is this the long term plan for saving configurations?
> 
> I'm hoping that we can move drop current serialization style storage  of 
> configurations.  XStream, like Java Object Serialization,  decomposes 
> complex objects and writes the reconstruction recipe to  the file.  
> Instead of this, I think we should take a Spring approach  and in our 
> deployment process, create the object construction recipes  directly 
> (instead of reverse engineering the complex objects).  With  a recipe 
> based deployment system, we should have much cleaner  configuration xml 
> files for which we can create a schema, and it will  be easier to 
> integrate with Spring.  (I have some of this conversion  done in a 
> branch of HEAD on my laptop).
> 
> 
> -dain
> 
> 
> 

Mime
View raw message