Jason, Jason Chodakowski wrote: > By adding something onto the URL (we're using serialize=true) we wanted > to write the entire Context of a given request/response to disk... that > way an web-editor-type could use our widget to gather a fully-formed > Context, loaded from disk, without needing live connections to a > database, an application server container, etc. to view an > assembled/parsed page - just a small Java program which can load that > Object from disk, and then do a mergeTemplate type action to produce > completed HTML for the editor-of-choice.
Instead of worrying about serialization, you could just write your
program to load sample objects that you either hard-code or put into
properties files or something. I suppose more complex objects could be
serialized, too.
Since serialization of the Context would require every object inside of
it to be serialized, you could just serialize each name/value pair from
the Context separately, and then re-build the Context in your little
mack-up program. This would avoid you having to hack around the Context
code, etc.
Oddly, both InternalContextBase and VelocityContext contain
serialVersionUIDs, but do not implement Serializable.
InternalContextBase also contains some runtime-only data, such as the
template (name) stack, macro (name) stack, and a few other things. Most
of this sounds like it could be transient, and ignored for serialization
purposes (but you have to be careful to re-initialize those resources
after a de-serialization).
Simple serialization would require the following classes to be made
serializable:
- Context (the interface)
- InternalContextBase (relatively easy, but has deps)
- AbstractContext (trivial)
- VelocityContext (trivial, assuming that the Map used is
Serializable)
- EventCartridge
- EventHandler & friends
- Resource & friends
Ugh.... I give up. Why do we need serializable Contexts again?
-chris
signature.asc
Description: OpenPGP digital signature
