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 <[EMAIL PROTECTED]> 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/
