geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <sppat...@gmail.com>
Subject Re: New Feature: XML based configurations
Date Tue, 04 Apr 2006 23:51:48 GMT
awesome!

- sachin



On Apr 4, 2006, at 6:52 PM, 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.kerne 
> l.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.kerne 
> l.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