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
