Patrick, 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 annotations. 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? Kevin On 11/26/06, Patrick Linskey <[EMAIL PROTECTED]> 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="http://java.sun.com/xml/ns/persistence/orm"; xmlns:openjpa="http://...."; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm 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.
