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
