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-enhan
ced
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-enhan
ced
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 track
ing
will occur on the unmarshalled instance."

Regards,

Erik Bengtson

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Craig,

There are two cases: Classes using default Serialization and classes with Us
er
Serialization Code.

In all cases the User must add serialVersionId field to the non enhanced cla
ss.

Default Serialization:

The default serialization will take care of dropping the jdoDetachedState. T
he
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:
> 
>
> 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!
>
>

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

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 ar
e
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 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!
>
>

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

Craig,

I don't mean any changes to attachment or detachment detection. Once the
jdoDetachedState is lost, attachment will not work.

My proposition (serialization) is already a mechanism that works by the JDO 
2
spec, and just need a clarification to the spec saying that if the user adds
the serialVersionId it becomes compatible (enhanced vs non-enhanced), but th
e
jdoDetachedState is lost.

Regards,

Quoting Craig L Russell <Craig.Russell@Sun.COM>:

> Hi Erik,
>
> The way to send objects to a remote site using the standard
> serialization contract is to define the classes as not detachable.
>
> We looked at the issue of detaching and attaching instances of
> classes that had no detachment information very early in the JDO 2.0
> cycle and concluded that there was no standard way to detect changes
> and know whether nulls meant "not loaded" or "no reference".
>
> If you are working with simple instances where detachment information
> is not needed, then you can use non-detachable classes. Then the
> primary issue is detecting that an instance is detached, not new.
>
> By the way, the Java Persistence specification is quite vague on all
> of the above issues, and in my opinion does not solve the problem.
>
> If you want to propose some standard behavior that allows an
> implementation to reliably determine whether an instance of a non-
> detachable  class is detached, that's the place to start. You might
> try to come up with some algorithm using the optional version field
> and optional primary key field and might have some luck.
>
> As I recall, there are no TCK tests that try to detach instances of
> non-detachable classes and later attach the instances. So there is no
> gotcha there.
>
> Craig
>
> On May 7, 2007, at 11:26 PM, Erik Bengtson wrote:
> 
>
> 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!
>
>

[ Post a follow-up to this message ]

Ops,

This is already in the spec §21.6


Quoting Erik Bengtson <erik@jpox.org>:

> Craig,
>
> I don't mean any changes to attachment or detachment detection. Once the
> jdoDetachedState is lost, attachment will not work.
>
> My proposition (serialization) is already a mechanism that works by the JD
O 2
> spec, and just need a clarification to the spec saying that if the user ad
ds
> the serialVersionId it becomes compatible (enhanced vs non-enhanced), but 
the
> jdoDetachedState is lost.
>
> Regards,
>
> Quoting Craig L Russell <Craig.Russell@Sun.COM>:
> 
>
>
>
>

[ Post a follow-up to this message ]