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
