Hello Craig,
This is how we interpret the specification as well and how property access works in TopLink?
I think perhaps you may be confused by my answer to the question Marina had asked about the warning she was seeing. Hopefully with more specifics I can clear up your confusion.
Within TopLink properties are accessed and set through the corresponding accessor and mutator only. There is no access to the underlying field. In fact with property access there is no way to know what field will be used or if there is a field at all.
The, poorly worded, warning that Marina mentioned is from our TopLink 10.1.3 EJB 3.0 Preview support and is applicable only to the enhancement of user code to support lazy loading of One-to-one (and many-to-one) relationships. In the Preview we chose to extend this enhancement to properties in the case that there was an underlying field of the same name. This, although not a robust choice (it is error prone in cases where the property accessors are not simple wrappers of the class fields), provided the majority of users with lazy one-to-one property access without much work on our end. The warning states that we are unable to enhance the class because the property is not a simple wrapper for an underlying field. This did not change the way TopLink accesses the properties but simply changed the lazy loading behaviour.
At this time we have a bug to remove this enhancement and provide a robust option for one-to-one mapped properties. This work will be completed before the final delivery but as it has yet to cause any issues with the testing it has not been a high priority
Hopefully I have cleared up your questions?
--Gordon
-----Original Message-----
From: craig.russell_at_sun.com [mailto:craig.russell_at_sun.com]On Behalf Of Craig L Russell
Sent: Wednesday, November 30, 2005 2:49 PM
To: persistence_at_glassfish.dev.java.net
Cc: Marina Vatkina; ejb3-toplink-ext_at_sun.COM
Subject: "Abstract" persistent properties (without a field of the same name)
Hi Gordon,
As we discussed briefly on today's phone conference, I didn't see anywhere in the spec that the persistence provider is allowed to use a field to store persistent properties. I thought it would be good to have an email trail of the discussion.
My understanding is that the fields that back the property belong to the user; the provider is only supposed to use the get/set methods; and it's just not legal for the provider to access any fields except for persistent fields.
Thanks,
Craig
On Nov 29, 2005, at 7:54 AM, Gordon Yorke wrote:
The property warning is simply a warning notifying the user that because they have choosen to use abstract properties (properties without a field) the relationship will be eagerly retreived. From a functional point of view the end user should not notice a difference. It is also spec compliant as fetch types are suggestions within the Spec.
--Gordon
-----Original Message-----
From: mvatkina_at_ha21sca-mail1.SFBay.Sun.COM
[mailto:mvatkina_at_ha21sca-mail1.SFBay.Sun.COM]On Behalf Of Marina Vatkina
Sent: Monday, November 28, 2005 8:44 PM
To: ejb3-toplink-ext_at_sun.COM; persistence_at_glassfish.dev.java.net
Subject: [Fwd: bugs or user error?]
Team,
This is another email that I've sent on Tuesday
with no luck of getting through :(.
thanks,
-marina
-------- Original Message --------
Subject: bugs or user error?
Date: Tue, 22 Nov 2005 13:20:24 -0800
From: Marina Vatkina <marina.vatkina_at_sun.COM>
To: "persistence_at_glassfish.dev.java.net" <persistence_at_glassfish.dev.java.net>
Team,
I encountered the following problems while running my simple test:
1. With property-based persistence (the default, right?), if I do *not*
have a field that matches exactly the name of property for lazy loading
(e.g. 'cust' vs. getCustomer()), I get the following warning in Java SE
(I didn't check Java EE yet):
--Weaving for valueholders not enabled for class [entity.Order] because it does
not have field [customer].
2. Remove of an instance fetched in the same tx throws an exception that
it's detached:
Exception in thread "main" java.lang.IllegalArgumentException: Entity must be
managed to call remove: entity.Customer_at_10849bc, try merging the detatched and
try the remove again.
at
oracle.toplink.essentials.internal.sessions.UnitOfWorkImpl.performRemove(UnitOfWorkImpl.java:2711)
at
oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.remove(EntityManagerImpl.java:117)
Are these bugs or my errors?
thanks,
-marina
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!