[
https://issues.apache.org/jira/browse/OPENJPA-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859872#action_12859872
]
Jeremy Bauer commented on OPENJPA-1613:
---------------------------------------
Committed a fix under rev 936930 which included a slightly modified version of
Simon's testcase.
As of this commit, OpenJPA will now take @javax.persistence.Transient fields
and properties into consideration when making a default access determination.
This is consistent with the JPA specifications and OpenJPA 1.x behavior.
However, OpenJPA 2.x does not completely mimic 1.x behavior regarding
persistent properties. The provided test application exposed another
inconsistency between OpenJPA 1.x and 2.x. OpenJPA 2.x does more stringent
verification on persistent properties. Per spec,
<jpa 2.0 spec>
In this case, for every persistent property property of type T of the entity,
there is a getter method, get-
Property, and setter method setProperty. For boolean properties, isProperty may
be used as an alternative
name for the getter method.
For single-valued persistent properties, these method signatures are:
• T getProperty()
• void setProperty(T t)
</jpa 2.0 spec>
The supplied test application patch did not have a matching setter for the
getter. OpenJPA 1.x took the @Transient getter into account when making the
default access determination - but dumped this message regarding the property:
<OpenJPA 1.x>
No setter was found for method someProperty in type test.AbstractSuperclass
while searching for persistent properties. This method will be ignored. If you
intended for this to be persistent, please add a corresponding setter, or
switch to field access for this type hierarchy.
</OpenJPA 1.x>
This is an inconsistency in the 1.x code base. I think a property should only
be considered in the access calculation only if the property is/can be
persistent. As of this commit, OpenJPA 2.0 will only take the @Transient
property into the default access calculation if the property is persistent (has
a matching getter/setter). Thus, I made a small change to the test code to
ensure the @Transient property is in the format defined by the spec.
> Exception thrown when enhancing a (property access) class that has an
> abstract @MappedSuperclass with no annotated properties
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-1613
> URL: https://issues.apache.org/jira/browse/OPENJPA-1613
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 2.0.0-beta2, 2.0.0-beta3
> Reporter: Simon Droscher
> Assignee: Jeremy Bauer
> Fix For: 2.0.1
>
> Attachments: abstract-subclass.patch,
> OPENJPA-1613-failing-code-changes.diff, OPENJPA-1613-tests.diff
>
>
> If you have a class (using property access) that has an abstract
> @MappedSuperclass that happens to have no annotated methods, you get the
> following exception when enhancing:
> org.apache.openjpa.util.MetaDataException: "implicit property access" for
> class "org.apache.openjpa.persistence.simple.SubclassPerson" is not
> consistent with "implicit field access" used by its persistent superclass
> "org.apache.openjpa.persistence.simple.AbstractSuperclass". All persistent
> classes in an inheritance hierarchy must use a single implicit field or
> property based access style or explicitly declare an access style.
> Presumably the enhancer is deciding incorrectly that the superclass is using
> field access. A workaround is to annotate the superclass with
> @Access(AccessType.PROPERTY) so the enhancer doesn't make this assumption,
> but that is not JPA 1.0 backwards compatible.
> This did not occur in any of the OpenJPA 1.* versions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
