openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Bauer (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OPENJPA-1613) Exception thrown when enhancing a (property access) class that has an abstract @MappedSuperclass with no annotated properties
Date Thu, 22 Apr 2010 16:35:49 GMT

    [ 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.


Mime
View raw message