geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: [POLL] API and Implementation serialization compatibility and upgrading
Date Sun, 15 May 2005 02:30:20 GMT
Just FYI, "entire runtime object serialized (axis integration)" was a
choice...usually Axis uses a deployment descriptor (even jonas uses
these xml based wsdd descriptors)....but the decision to use
serialized runtime objects was conscious one in Geronimo.

Yes, need more information...(or more time to think i guess). But i
guess we can force people to re-deploy when they upgrade...if that is
the only choice.

-- dims

On 5/14/05, David Jencks <djencks@gluecode.com> wrote:
> 
> On May 14, 2005, at 7:28 AM, 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.
> 
> I think this is wrong.  IIUC we serialize gbean attribute values and
> reference patterns.  We also serialize a few classes from the kernel to
> hold all that stuff.  Depending on which module you are talking about,
> the gbean attributes could be entirely plain java types (transaction),
> plain java + a few "data only" classes (connector, jetty), large
> numbers of implementation classes together with some java (openejb), or
> the entire runtime object serialized (axis integration).
> 
> So, there are 2 dimensions of incompatibility: GBeanInfo definitions
> and the classes of GBean attributes.  With care we might be able to
> make gbean infos upward compatible by only adding attributes and
> references and supplying in code default values when the new ones are
> missing.  Data only classes are perhaps not all that likely to change
> incompatibly if they are designed well enough to begin with.  The big
> problem comes when we are using large parts of the implementation as
> attributes.  It  might be worth considering if it would be practical to
> make more of the attributes data-like.
> 
> >
> > 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.
> 
> I think what we can't change is the GBeanInfo definitions and the
> classes used as attributes.
> 
> thanks
> david jencks
> 
> >   - 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
> >
> >
> 
> 


-- 
Davanum Srinivas - http://webservices.apache.org/~dims/

Mime
View raw message