Hi,

This doesn't seem to be an unreasonable restriction, but if it's not in the spec we should clarify the spec. If it isn't reasonable, we will need to look at the TCK and make sure that we don't require anything that the spec doesn't require.

Craig

On Apr 2, 2005, at 1:04 AM, Eric Samson wrote:

Erik

In LiDO when an attribute is a java.lang.Object we don't impose the
referenced object to be serializable if it is a PC. But if it is not a PC it
must be Serializable, as for embedded objects.

Best Regards
.:
Eric Samson, xcalia

-----Message d'origine-----
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Envoy� : samedi 2 avril 2005 10:19
� : [email protected]; 'JDO Expert Group'
Objet : RE: updates to tck11 project

If all implementations require that Object type fields to implement
Serializable, in the JDO spec we should mention it and in the TCK classes
should implement Serializable.

The only thing I don't want is to have to hack the TCK in order to pass the
tests.

Erik Bengtson

-----Original Message-----
From: Craig Russell [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 02, 2005 2:33 AM
To: JDO Expert Group; [email protected]
Subject: Re: updates to tck11 project

Hi,

I'm not sure what the question is here. Is it whether the TCK correctly
tests the Object field type?

Craig

On Apr 1, 2005, at 1:39 PM, Matthew T. Adams wrote:

From a specification standpoint (I just checked), I guess you can
require that your users make their Object-typed field instances
serializable (section 6.4.3), since you are allowed to restrict the
instances that can be stored in these cases.  If they don't implement
Serializable, you can throw a ClassCastException and still be
compliant
with the spec.

<quotation>
Object Class type
JDO implementations must support fields of Object class type as FCOs.
The implementation
is permitted, but is not required, to allow any class to be assigned
to
the field. If an implementation
restricts instances to be assigned to the field, a ClassCastException
must be thrown at the time of any incorrect assignment.

Portable JDO applications must not depend on whether these fields are
treated as SCOs or FCOs.
</quotation>

--matthew

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 12:47 PM
To: [EMAIL PROTECTED]
Cc: [email protected]; [EMAIL PROTECTED]
Subject: RE: updates to tck11 project


I ask if a JDO implementation, in order to support java.lang.Object, can require from the classes to be persisted to implement Serializable.

Are there any requirements from LIDO to store Object types?

Quoting "Matthew T. Adams" <[EMAIL PROTECTED]>:

LiDO supports it. Any instance stored in the field whose
type is Object
must be either a PC, a PI, or custom-mapped.

--matthew

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 11:09 AM
To: [email protected]
Cc: [EMAIL PROTECTED]
Subject: RE: updates to tck11 project


I wonder if we require developers willing to store java.lang.Object implement Serializable interface. JPOX requires it, what
about others?

Currently, the TCK does not implement Serializable.


Erik Bengtson

-----Original Message-----
From: Michelle Caisse [mailto:[EMAIL PROTECTED]
Sent: Friday, April 01, 2005 7:21 AM
To: [email protected]
Subject: updates to tck11 project

Hi,

I have made the following commits to tck11:

-  Fixed problem with Oid classes reported by Erik
-  Fixed a couple of minor problems with maven.xml in the
runtck.single and enhance.*identity goals.

-- Michelle












Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!




Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature



Reply via email to