openjpa-dev mailing list archives

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


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

class MySuper {

  private String name;

  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.
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:
>             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,
> 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.

View raw message