geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject New Feature: XML based configurations
Date Tue, 04 Apr 2006 22:52:35 GMT
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 - 
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 - 
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  This will  
allow us to patch jars and classes in an existing server and work  
with libraries that don't properly implement

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


View raw message