[
https://issues.apache.org/jira/browse/OPENJPA-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12859079#action_12859079
]
Jeremy Bauer commented on OPENJPA-1613:
---------------------------------------
I ran some comparisons between OpenJPA 1.2.2 and 2.0.x. Version 1.2.2 is
picking up the @javax.persistence.Transient annotation on the property in
AbstractSuperclass and using this annotation to trigger property access by
default. Based on the JPA 1.0 spec (and carried forward to the 2.0 spec):
<jpa 1.0 - section 2.1.1>
When annotations are used, the placement of the mapping annotations on either
the persistent fields or persistent properties of the entity class specifies
the access type as being either field- or property-based access respectively.
</jpa 1.0>
As you can see the spec uses "annotations" freely in this context. Can this be
inferred to include all javax.persistence annotations, including Transient? If
so, it would follow that this mapped superclass definition would/should result
in an ambiguous access type exception: (which it does in OpenJPA 1.2.2 - not
currently in OpenJPA 2.0.x - 2.0.x defaults to field access)
@MappedSuperclass
class MySuper {
@Transient
private String name;
@Transient
private Address getAddress() { ... }
private void setAddress(Address a) { ... }
}
As Donald mentioned, OpenJPA 2.x.x currently ignores fields and methods tagged
with the @Transient annotation when calculating the default access type.
Should OpenJPA take @Transient into account when deciding which access type to
choose? It is a very odd case where this annotation alone would be the
deciding factor. Regarding @Transient the 1.0 spec simply states:
<jpa 1.0 - section 2.1.1>
All non-transient instance variables that are not annotated with the Transient
annotation are persistent.
and
All properties not annotated with the Transient annotation are persistent.
</jpa 1.0 -section 2.1.1>
As Donald also points out, the 2.0 spec adds:
<jpa 2.0 - section 2.3.1>
It is an error if a default access type cannot be determined and an access type
is not explicitly specified by means of annotations or the XML descriptor. The
behavior of applications that mix the placement of annotations on fields and
properties within an entity hierarchy without explicitly specifying the Access
annotation is undefined.
</jpa 2.0 - section 2.3.1>
Looking at this specific case - it seems odd that @MappedSuperclass is used on
an class with no persistent state. If that is true, you could eliminate
@MappedSuperclass from AbstractSuperclass. Extending a non-persistent Java
class is possible with OpenJPA.
Regardless, based on the verbiage in the spec and given the behavior of prior
releases of OpenJPA, it would seem that using @Transient to detect the default
access type is what OpenJPA should do. Opinions, please!
> 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.
