Re: OpenJPA annotations XML
Kevin Sutter wrote: > > 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. > But using an openjpa namespace still makes it valid XML. Really its then an implementation issue how the providers handle unknown namespaces. Sounds like a great idea to me (using openjpa:*) - much cleaner than JDO's tags. > 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? > http://issues.apache.org/jira/browse/OPENJPA-87 > 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 , 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: >> >> 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"> >> >> com.example.jpa >> >> >> >> >> >> >> >> >> >> >> >> >> 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. >> > > -- View this message in context: http://www.nabble.com/OpenJPA-annotations-XML-tf2709559.html#a7711090 Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: OpenJPA annotations XML
> 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. But do we care? That is, how do we want to balance portability vs. ease of use? Put another way, if we were to define schema extensions, we could presumably allow both interleaving of the contents as in my example and parallel files, so that people could choose how they wanted to configure. This would have the downside of allowing multiple configuration mechanisms, but would allow the upside of letting people use one file instead of two if they so desired. > 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? Currently, I believe that that is the case. > If I am reading that right, > then isn't this just a bug that needs to be resolved? Yes, but the fix has implications on behavior in the future, if we decide to have a single file instead of multiple. > 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. No, OpenJPA doesn't provide any way to override JPA annotations / descriptor elements. > On a related note... Will the xml-mapping-metadata-complete > element apply > to the openjpa annotations as well? If we put contents into the same file, I'd say yes. If we put contents into a different file, dunno. Maybe we'd want to have another xml-mapping-metadata-complete stanza there too. -Patrick ___ 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.
Re: OpenJPA annotations XML
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 , 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: 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"> com.example.jpa 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.
