geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: [POLL] API and Implementation serialization compatibility and upgrading
Date Sat, 14 May 2005 22:12:22 GMT

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
>
>


Mime
View raw message