db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bengtson <e...@jpox.org>
Subject Re: detachable vs non detachable classes serialization compatible
Date Tue, 08 May 2007 06:26:14 GMT
Craig,

The use case is a remote application that does have jdo.jar in the classpath.
This application invoke RMI operations to a server where enhanced objects are
returned, but the application has an un-enhanced version of the class.

Regards,
Quoting Craig L Russell <Craig.Russell@sun.com>:

> Hi Erik,
>
> These are implementation details. Can you explain what the user
> behavior is, and the use case?
>
> Thanks,
>
> Craig
>
> On May 7, 2007, at 5:31 PM, Erik Bengtson wrote:
>
> > Craig,
> >
> > There are two cases: Classes using default Serialization and
> > classes with User
> > Serialization Code.
> >
> > In all cases the User must add serialVersionId field to the non
> > enhanced class.
> >
> > Default Serialization:
> >
> > The default serialization will take care of dropping the
> > jdoDetachedState. The
> > enhancer adds the following:
> >
> > private writeObject (OutputStream os) //enhanced
> > {
> > jdoPreSerialize();
> > os.defaultWriteObject()
> > }
> >
> > User Serialization (user defined writeObject and readObject methods):
> >
> > private writeObject (OutputStream os)
> > {
> > jdoPreSerialize(); //enhanced
> > //user serialization
> > os.writeObject(jdoDetachedState) //enhanced
> > }
> >
> > private readObject (OutputStream os)
> > {
> > //user serialization
> > jdoDetachedState = os.readObject(); //enhanced
> > }
> >
> >
> >
> > Quoting Craig L Russell <Craig.Russell@sun.com>:
> >
> >> Hi Erik,
> >>
> >> It would help if you could explain what you have in mind with this
> >> change. The decision to make the detachable serialization contract
> >> incompatible was deliberate, and the objective is to guarantee that
> >> attaching a detached instance behaves correctly.
> >>
> >> If you want a detached instance simply to send it away and never
> >> expect to see it again, your proposal might be of interest. Is that
> >> what you had in mind?
> >>
> >> Do you have some ideas on how to implement this feature? Seems that
> >> if the unenhanced class is given an input stream with the detached
> >> info in the serialized form of the instance, it's going to run into
> >> an exception (unless you modify the unenhanced class, perhaps with a
> >> byte-code enhancer).
> >>
> >> Thanks,
> >>
> >> Craig
> >>
> >> On May 6, 2007, at 5:39 AM, Erik Bengtson wrote:
> >>
> >>> Hi,
> >>>
> >>> The spec says classes that detachable and non detachable classes
> >>> are not
> >>> compatible intentionally. I would like to propose a change to this
> >>> behavior and
> >>> let the “jdoDetachedState” lose on unmarshalling.
> >>>
> >>> From:
> >>> "Classes marked as Detachable are not serialization-compatible with
> >>> un-enhanced
> >>> classes. This is intentional, and requires that the enhanced
> >>> version of the
> >>> class be used wherever the instance might be instantiated."
> >>>
> >>> To:
> >>> "Classes marked as Detachable are not serialization-compatible with
> >>> un-enhanced
> >>> classes. When unmarshalling a detached object with an un-enhanced
> >>> version of
> >>> the class, the detached state is dropped and no further read or
> >>> change tracking
> >>> will occur on the unmarshalled instance."
> >>>
> >>> Regards,
> >>>
> >>> Erik Bengtson
> >>
> >> Craig Russell
> >> Architect, Sun Java Enterprise System http://java.sun.com/products/
> >> jdo
> >> 408 276-5638 mailto:Craig.Russell@sun.com
> >> P.S. A good JDO? O, Gasp!
> >>
> >>
> >
> >
> >
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>




Mime
View raw message