openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <>
Subject Re: OpenJPA annotations XML
Date Tue, 05 Dec 2006 16:20:22 GMT
Not getting a lot of activity on this thread yet...  I'll kick in my two
cents worth...

I agree with your overall direction -- attempting to keep the annotation
support in synch with the xml support as outlined in the JPA spec.  All
annotations defined by the JPA spec seem to have a corresponding xml
override.  We probably need to do something similar for our OpenJPA

As you have pointed out, this gets a bit trickier due to the xml schema
definitions for the orm.xml file.  We can't just define new stanzas and
expect the orm.xml files to be portable across persistence providers.

Your second guideline was a surprise to me.  Are you saying that if an
application is using orm.xml to override certain spec-compliant annotations,
then the OpenJPA annotations are also ignored?  If I am reading that right,
then isn't this just a bug that needs to be resolved?  Does OpenJPA provide
alternative annotation support for the JPA spec-compliant annotations?  I
knew we provided additional annotations, but I wasn't aware that we overrode
JPA annotations.

It would seem that if we want OpenJPA applications to be portable across
persistence providers, then we would need a separate XML schema for our
extensions.  Our customers would then have to provide something like an
OpenJPAorm.xml file.  Not ideal, but workable.  Your example below shows the
use of an openjpa-qualified element <openjpa:data-cache/>, but will other
parsers safely ignore these items that are not recognized?

On a related note...  Will the xml-mapping-metadata-complete element apply
to the openjpa annotations as well?


On 11/26/06, Patrick Linskey <> wrote:
> The JPA spec defines entity annotations and a corresponding XML
> deployment descriptor format (the orm.xml format, not the
> persistence.xml format). The XML deployment descriptor data overrides
> the annotation data, and does so on a per-attribute basis. This means
> that if there is an XML element for a given persistent field / property
> (attribute), then the data in the XML is used, and any data in the
> annotation is ignored.
> OpenJPA further defines some of its own entity annotations. However,
> currently, these annotations cannot be expressed in XML.
> (IMO, configuring OpenJPA extensions in XML is more important for the
> JDBC-related annotations than for the non-JDBC annotations, as the
> non-JDBC annotations are largely things that I think annotations are
> suitable for. My litmus test is that if something is intrinsic to the
> class when the class is designed, it makes sense as an annotation;
> otherwise, it should be externalized from the class.)
> The goal of this message is to kick off a discussion about what we want
> the XML configuration pathway to look for OpenJPA. I'll start off with a
> couple of high-level guidelines:
> 1. XML configuration should parallel the rules and conventions of the
> JPA spec.
> 2. The rules for overriding annotations should be carefully thought out.
> In particular, how do we design a long-term solution *and* resolve the
> short-term issue that currently prevents OpenJPA annotations from being
> picked up if spec XML is used?
> I think that my ideal solution would be one that allowed the
> OpenJPA-specific info to be placed inline inside the orm.xml file, maybe
> like so:
> <entity-mappings xmlns=""
> xmlns:openjpa="http://...."
> xmlns:xsi=""
> xsi:schemaLocation="
> orm_1_0.xsd" version="1.0">
>     <package>
>         com.example.jpa
>     </package>
>     <entity class="Person">
>         <openjpa:data-cache/>
>         <attributes>
>             <id name="pk"/>
>             <basic name="firstName"/>
>             <basic name="lastName"/>
>         </attributes>
>     </entity>
> </entity-mappings>
> Thoughts?
> -Patrick
> --
> Patrick Linskey
> BEA Systems, Inc.
> _______________________________________________________________________
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual
> or entity named in this message. If you are not the intended recipient,
> and have received this message in error, please immediately return this
> by email and then delete it.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message