Property access validation rules (was: RE: Troubleshooting help)

[Patrick Linskey <pl...@bea.com>]

> -----Original Message-----
> From: Craig.Russell@Sun.COM [mailto:Craig.Russell@Sun.COM] 
> Sent: Monday, January 08, 2007 9:01 PM
> To: open-jpa-dev@incubator.apache.org
> Subject: Troubleshooting help
> 
> ...
> 
>      [java] 6222  WARN   [OCDriverAllOpsAgent[0].0] 
> openjpa.Enhance - Detected the following possible violations 
> of the restrictions placed on property access persistent types:
>      [java] "pb.common.Assembly" uses property access, but 
> its field "purchased" is accessed directly in method 
> "writeObject" defined in "pb.common.Assembly".
>      [java] "pb.common.Assembly" uses property access, but 
> its field "planner" is accessed directly in method 
> "readObject" defined in "pb.common.Assembly".

I understand that writeObject() should not be using fields directly, but
it would seem to me that it's fine for readObject() to set fields
directly, since readObject() is (presumably) only invoked during
deserialization, and during deserialization an instance cannot be
managed.

It would seem that we should special-case 'void
readObject(ObjectOutputStream)', 'Object readResolve()', and
'Externalizable.readExternal(ObjectInput)'. 

Also, given the text in 2.1.1 of the JPA spec:

"If property-based access is used and lazy fetching is 
specified, portable applications should not directly
access the entity state underlying the property methods 
of managed instances until after it has been fetched by 
the persistence provider."

we might want to not generate warnings for read access to fields that
are in the default fetch group.

Thoughts?

-Patrick
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.