What's the reason for originally deciding to go with object
serialization to store configuration *data* instead of some text format,
say an XML format?
Sanjiva.
On Mon, 2005-05-16 at 08:44 -0700, David Blevins wrote:
> Nice spin. Though you're joking around, I'll answer seriously.
>
> PROJECTS:
> Again we are talking about changed class files, which can result from a patch
> or upgrade. When people make things serializable, they are only guaranteeing
> that data serialized from that class and be deserialized back into that exact
> class. They are not making claims of past or future versions of that class.
>
> USERS:
> Users do care about incompatibilities between minor dot and patch releases.
> But users do not care about compatibility of private class files between
> minor dot and patch releases. But as the storage format for configuration
> data is public and private class files, we have made this their problem at
> upgrade/patch time.
>
> -David
>
> On Sat, May 14, 2005 at 08:14:49PM -0700, Jeremy Boynes wrote:
> > <humor>
> > Oh, for Pete's sake, this poll is about as Fair and Balanced as Fox News.
> >
> > How about:
> >
> > PROJECT POLL:
> > [ ] We, ${projectName}, didn't really mean it when we said something
> > was Serializable and feel free to change our APIs and
> > implementation at any time without telling you.
> >
> > [ ] We do our best to ensure our public APIs, but use of them is not
> > supported by us. Good luck guys.
> >
> > USER POLL:
> > [ ] I am a ${otherProject} user and quite like the incompatibilities
> > between even minor dot releases - it gives my admins something to
> > do. Please make sure ${projectName} behaves this way as well
> >
> > [ ] I believe the safest way to upgrade something is to wipe out
> > everything that is there and start over every time. That way
> > I don't get cooties from old software.
> >
> > </humor>
> >
> > OK, so it probably isn't that funny but let's at least have a serious
> > discussion about this.
> >
> > --
> > Jeremy
> >
> > David Blevins wrote:
> > >I really want to get some feedback from the developers, users, lurkers,
> > >other projects and everyone on this subject. It shouldn't be a taboo to
> > >talk about or considered a "can of worms" or a "hot button." It affects
> > >the project at pretty fundamental level, so I think it would be good if we
> > >did our best to get feedback.
> > >
> > >The problem:
> > >
> > > Upgrading apps between versions of Geronimo and it's integrated projects
> > > is not currently possible without a redeploy.
> > >
> > >The facts:
> > > - Our deploy system and storage of deployed apps is serialization based.
> > > - At deploy time we build and Jetty web containers, Tomcat web
> > > containers, ActiveMQ queues/topics, OpenEJB ejb containers, Axis
> > > webservices, TranQL connectors and more
> > > - We serialize those objects which include not just what they consider
> > > to be their public APIs but also the private implementations of those
> > > APIs.
> > >
> > >The tricky part:
> > > - We, qualified in alphabetical order, ActiveMQ, Axis, Geronimo, Jetty,
> > > OpenEJB, Tomcat, TranQL, et. al. cannot change our public API *or*
> > > private Implementation of our APIs and still deserialize objects from a
> > > previous version.
> > > - Unless we (the projecst above) agree not to bug fix, optimize,
> > > refactor, repackage, or reorganize our code in a way that would break
> > > deserialization of objects created with a previous versions of our code,
> > > it will not be possible to upgrade applications leveraging these
> > > projects without a redeploy.
> > >
> > >
> > >PROJECT POLL:
> > > [ ] We will do our best to ensure the implementations of our APIs are
> > > serialization compatible to future versions of our code.
> > > [ ] We do our best to ensure our public APIs, but use of our
> > > implementations in such a way is not supported by us.
> > >
> > >USER POLL:
> > > [ ] I do not mind redeploying my applications on each upgrade of
> > > Geronimo et. al.
> > > [ ] I do not want to start from scratch on each upgrade of Geronimo et.
> > > al.
> > >
> > >
> > >
> > >-David
> > >
> > >
> >
>
> LocalWords: Boynes
>
