You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Matthew Adams <ma...@xcalia.com> on 2007/02/23 22:33:06 UTC
[DISCUSS] Named PMF proposal (JDOHelper enhancements)
This is a proposal we discussed on the Fri Feb 23 JDO conf call. Please
review and discuss.
Overview:
Currently, there is no way to bootstrap a JDO implementation completely
externally to the source code. The developer is required to provide at
least a resource name that identifies a java.util.Properties file on the
classpath that can configure a single PMF. This makes deployment in
different environments more challenging than necessary.
Motivation:
* Source code is required to be aware of external configuration:
* In all current JDOHelper.getPersistenceManagerFactory APIs and
* in order to configure listeners.
* Aligns JDO bootstrapping with JPA bootstrapping concepts.
Proposed Solution:
* Introduce new API methods and JDO equivalent of the JPA persistence
unit concepts, including a jdo.xml file that provides for the
configuration of one or more named PMFs.
Details:
* PersistenceManagerFactory additions
/** Returns the persistence unit name of this PMF. It's the JPA
persistence unit name if configured via persistence.xml or the JDO
persistence unit name if configured via javax.jdo.xml. */
public String getName();
* JDOHelper API additions
/** The default name of the JDO configuration file. */
public static final String DEFAULT_JDO_CONFIG_RESOURCE_NAME =
"javax.jdo.xml";
/** The name of the default persistence unit. */
public static final String DEFAULT_PMF_NAME = "default";
/** Gets the PMF named "default" in the resource "javax.jdo.xml" found
via the current ClassLoader. */
public static PersistenceManagerFactory getPersistenceFactoryManager() {
return getPersistenceFactoryManagerByName(DEFAULT_PMF_NAME);
}
/** Gets the PMF named pmfName in the resource "javax.jdo.xml" found via
the current ClassLoader. */
public static PersistenceManagerFactory
getPersistenceManagerFactoryByName(String pmfName) {
return getPersistenceFactoryManagerByName(DEFAULT_PMF_NAME,
DEFAULT_JDO_CONFIG_RESOURCE_NAME);
}
/** Gets the PMF named pmfName in the resource named resourceName found
via the current ClassLoader. */
public static PersistenceManagerFactory
getPersistenceManagerFactoryByName(String pmfName, String resourceName)
{
return getPersistenceFactoryManagerByName(DEFAULT_PMF_NAME,
DEFAULT_JDO_CONFIG_RESOURCE_NAME, getClass().getClassLoader());
}
/** Gets the PMF named pmfName in the resource named resourceName found
via the current ClassLoader. */
public static PersistenceManagerFactory
getPersistenceManagerFactoryByName(String pmfName, String resourceName,
ClassLoader loader) {
// reads resource resourceName via given loader
// configures & returns PMF with the given name
}
* Possibilities for DEFAULT_JDO_CONFIG_RESOURCE_NAME value:
need to determine file name (similar to persistence.xml)
javax.jdo.xml
jdo.xml
...
* Proposal for JDO persistence unit configuration XML file
* Could be more like Spring beans.xml (supporting references, etc.)
* Note: Square brackets indicate optional elements/attributes
<jdo-config>
[<extension> elements wherever appropriate]
<!-- Can use attributes for standardized properties -->
<!-- Can also support vendor-specific attributes and still validate
against schema -->
<persistence-manager-factory
[name="default"] <!-- no name implies only the default PMF,
named "default"; can only be one per file -->
[resource="..."] <!-- convenient for backward compatibility -->
[class="xcalia.ic.jdo.PersistenceManagerFactory"]
[connection-driver="..."]
[connection-url="..."]
[connection-user-name="..."]
[connection-password="..."]
[...]
>
<!-- or XML-friendly <property> elements -->
[<property name="javax.jdo...." value="..."/>]
[<property name="javax.jdo...." value="..."/>]
[<property name="xcalia.ic...." value="..."/>]
[...]
<!-- ...and/or properties in java.util.Properties file format?
overrides <property> elements? -->
<!-- This allows people to continue to use good, old
java.util.Properties format if they want -->
<properties><![CDATA[
javax.jdo....=...
javax.jdo....=...
xcalia.ic....=...
...
]]></properties>
<!-- This provides a way (currently, the only way) to configure
listeners outside of the code -->
<!-- We'd have to address any class loading issues, since we're
only given a class name -->
<!-- These should have javax.jdo.listener.... property &
property value equivalents in order to keep old-fashioned
java.util.Property-formatted values consistent with these values -->
<!-- Method names default to names of corresponding interfaces;
if not present on listener-class, they're a no-op or not even called -->
[<instance-lifecycle-listener
listener-class="my.jdo.InstanceListener"
classes-observed="my.domain.Foo,my.domain.Bar,.."
[static-factory-method="..."]
[pre-attach="preAttach"]
[post-attach="postAttach"]
[pre-store="preStore"]
[...]
/>]
<!-- The <instance-lifecycle-listener> element is sufficient,
but we could provide elements for each of the listener types -->
[<attach-lifecycle-listener
class="..."
[factory-method="..."]
[pre-attach="preAttach"]
[post-attach="postAttach"]
/>]
[...]
<!-- Can optionally include <jdo>, <orm> and <jdoquery> elements
here in order to override annotations, or developer-provided .jdo, .orm,
and/or .jdoquery files (from Erik Bengston) -->
<!-- Can add attribute to <jdo>, <orm>, and <jdoquery> to allow
for the specifiation of another resource or set of resources on the
classpath (from Craig Russell), for example: -->
<jdo
resources="META-INF/production-1;META-INF/production-2;..."/>
</persistence-manager-factory>
</jdo-config>
Matthew T. Adams
Senior Consultant & Product Marketing Director
Xcalia, Inc.
matthew.adams@xcalia.com
+1 206 331 3833 Office
+1 253 732 1051 Mobile
+1 815 331 0952 Fax
http://www.xcalia.com <http://www.xcalia.com/>
745 Emerson St.
Palo Alto, CA 94301
Xcalia provides dynamic integration software for agile enterprises to
easily create transactional composite applications. Our unique
intermediation approach enables unified, real-time access to
heterogenous data and services. Intermediation is adaptive and
configurable so application changes can be made quickly and cost
effectively without impacting the underlying systems or infrastructure.
Re: [DISCUSS] Named PMF proposal (JDOHelper enhancements)
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Matthew,
Yes, please create a JIRA and attach the xsd to it. You should attach
it as a text file (no .xsd suffix) so it can be viewed as text...
Thanks,
Craig
On Feb 23, 2007, at 4:19 PM, Matthew Adams wrote:
> Here is the XSD as a work in progress, in a pre-alpha state.
> Should we
> create a JIRA issue for this? Email seems nonideal for file
> management,
> especially when they're not attached.
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <xs:schema targetNamespace="http://java.sun.com/xml/ns/jdo/jdo-config"
> xmlns="http://java.sun.com/xml/ns/jdo/jdo-config"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> version="1.0">
>
> <!-- TODO: Decide if these should be imported, included, or
> copy/pasted
> <xs:import namespace="http://java.sun.com/xml/ns/jdo/jdo"
> schemaLocation="jdo.xsd"/>
> <xs:import namespace="http://java.sun.com/xml/ns/jdo/orm"
> schemaLocation="orm.xsd"/>
> <xs:import namespace="http://java.sun.com/xml/ns/jdo/jdoquery"
> schemaLocation="jdoquery.xsd"/>
> -->
> <xs:element name="jdo-config">
> <xs:complexType>
> <xs:sequence>
> <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="extension"/>
> <xs:sequence minOccurs="1" maxOccurs="unbounded">
> <xs:element name="persistence-manager-factory">
> <xs:complexType>
> <xs:choice>
> <xs:sequence minOccurs="0" maxOccurs="unbounded">
> <xs:element name="property">
> <xs:complexType>
> <xs:attributeGroup ref="attlist.property"/>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> <xs:element name="properties" type="xs:string"/>
> </xs:choice>
> <xs:attributeGroup
> ref="attlist.persistence-manager-factory"/>
> </xs:complexType>
> </xs:element>
> <xs:sequence minOccurs="0" maxOccurs="unbounded">
> <xs:element name="instance-lifecycle-listener">
> <xs:complexType>
> <xs:attributeGroup
> ref="attlist.instance-lifecycle-listener"/>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:sequence>
> <xs:element minOccurs="0" maxOccurs="unbounded"
> ref="extension"/>
> <!-- TODO: include sequences of <jdo [resources=""]>, <orm
> [resources=""]>, and <jdoquery [resources=""]> elements here -->
> </xs:sequence>
> <xs:attributeGroup ref="attlist.jdo-config"/>
> </xs:complexType>
> </xs:element>
> <xs:attributeGroup name="attlist.jdo-config"/>
> <xs:attributeGroup name="attlist.persistence-manager-factory">
> <xs:attribute name="name"/>
> <xs:attribute name="resource"/>
> <xs:attribute name="persistence-manager-factory-class"/>
> <xs:attribute name="optimistic"/>
> <xs:attribute name="retain-values"/>
> <xs:attribute name="restore-values"/>
> <xs:attribute name="ignore-cache"/>
> <xs:attribute name="nontransactional-read"/>
> <xs:attribute name="nontransactional-write"/>
> <xs:attribute name="multithreaded"/>
> <xs:attribute name="connection-driver-name"/>
> <xs:attribute name="connection-user-name"/>
> <xs:attribute name="connection-password"/>
> <xs:attribute name="connection-url"/>
> <xs:attribute name="connection-factory-name"/>
> <xs:attribute name="connection-factory2-name"/>
> <xs:attribute name="mapping"/>
> </xs:attributeGroup>
> <xs:attributeGroup name="attlist.property">
> <xs:attribute name="name"/>
> <xs:attribute name="value"/>
> </xs:attributeGroup>
> <xs:attributeGroup name="attlist.instance-lifecycle-listener">
> <xs:attribute name="post-attach"/>
> <xs:attribute name="pre-attach"/>
> <xs:attribute name="post-clear"/>
> <xs:attribute name="pre-clear"/>
> <xs:attribute name="post-create"/>
> <xs:attribute name="post-delete"/>
> <xs:attribute name="pre-delete"/>
> <xs:attribute name="post-detach"/>
> <xs:attribute name="pre-detach"/>
> <xs:attribute name="post-dirty"/>
> <xs:attribute name="pre-dirty"/>
> <xs:attribute name="post-load"/>
> <xs:attribute name="post-store"/>
> <xs:attribute name="pre-store"/>
> </xs:attributeGroup>
> <xs:element name="extension">
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="any">
> <xs:attributeGroup ref="attlist.extension"/>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
> <xs:attributeGroup name="attlist.extension">
> <xs:attribute name="vendor-name" use="required"/>
> <xs:attribute name="key"/>
> <xs:attribute name="value"/>
> </xs:attributeGroup>
> <xs:complexType name="any" mixed="true">
> <xs:sequence>
> <xs:any minOccurs="0" maxOccurs="unbounded"
> processContents="skip"/>
> </xs:sequence>
> </xs:complexType>
> </xs:schema>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: Named PM in addition to named PMF
Posted by Matthew Adams <ma...@xcalia.com>.
Hi Christian,
This smells like the userObject property/map allowable on the PM that
was present in JDO 1.0 and expanded in JDO 2.0. The only difference, if
I understand what you're saying, is that you would be able to get a PM
from a PMF by userObject, yes?
If so, this would require a method overload on PMF:
PersistenceManager getPersistenceManagerByUserObject(Object userObject);
Or something like this. Questions:
* This would require that all PMFs maintain a map of PMs by userObject,
yes? Is that reasonable to expect from implementations, or do we
consider another JDO option like
"javax.jdo.option.SupportsKeyedPersistenceManagers"?
* What would the PMF return if there were no userObject at that key in
the map? Null?
* How does this complement or conflict with the proposed PMF method
getPersistenceManagerProxy()? Is that sufficient? They smell kind of
similar to me.
-matthew
>-----Original Message-----
>From: Christian Ernst [mailto:cernst@versant.com]
>Sent: Wednesday, February 28, 2007 10:40 PM
>To: JDO Expert Group
>Cc: jdo-dev@db.apache.org
>Subject: Named PM in addition to named PMF
>
>Hi JDO friends !
>
>Following the discussion about named PMF,
>i would like to suggest to add also a name to PM.
>
>I think there are cases where it would be helpful to have a named PM.
>For Example:
>A named PM allows to track its PM / TXN via logging up to the Database
>Server ( assuming the Database Server allows somehow named TXN )
>It would allow explicit lookup via name from the PMF of a PM like
>JDOHelper.getPersistenceManagerFactoryByName("logistic").get.ge
>tPersistenceManagerByName("warehouseexit");
>
>
>Versant has already a vendor extension to set the name of the PM.
>The name is used in Backend Transaction and allows Customer
>much easier to track problematic long running or blocking Transactions
>and find the corresponding code in there Application.
>
>cheers
>Christian
>
>
>
>
>
Named PM in addition to named PMF
Posted by Christian Ernst <ce...@versant.com>.
Hi JDO friends !
Following the discussion about named PMF,
i would like to suggest to add also a name to PM.
I think there are cases where it would be helpful to have a named PM.
For Example:
A named PM allows to track its PM / TXN via logging up to the Database
Server ( assuming the Database Server allows somehow named TXN )
It would allow explicit lookup via name from the PMF of a PM like
JDOHelper.getPersistenceManagerFactoryByName("logistic").get.getPersistenceManagerByName("warehouseexit");
Versant has already a vendor extension to set the name of the PM.
The name is used in Backend Transaction and allows Customer
much easier to track problematic long running or blocking Transactions
and find the corresponding code in there Application.
cheers
Christian
Re: [DISCUSS] Named PMF proposal (JDOHelper enhancements)
Posted by Craig L Russell <Cr...@Sun.COM>.
On Feb 28, 2007, at 8:38 AM, Matthew Adams wrote:
> Inline...
>
>>> Call it what you want -- I only proposed these names. I
>> wouldn't call
>>> it persistence.xml, as the contents are not the same as the
>>> JPA-specified content. If the persistence.xml is found, its
>>> contents
>>> are of course interpretable by the JDO implementation
>> according to our
>>> JPA alignment verbage defined in JDO 2.1.
>>
>> ok. So a JDO2.1 impl has to understand both "persistence.xml"
>> (JPA format) and
>> this "jdo.xml" ? No problem if that is the case but just want
>> to understand
>> what we're specifying here since not everyone was on this conf call.
>>
> Yes, this is correct. I guess since JPA, which uses the base
> namespace
> "javax.persistence" and calls the file "persistence.xml", then we
> should
> probably call JDO bootstrap file "jdo.xml". Done.
I like it.
>
>>>> We could use the
>>>> same boot idea as JPA and have a
>> META-INF/services/javax.jdo.XXX file
>>>> defining the PMF(s) available, and it takes the one that
>>>> claims it supports
>>>> the required "persistence-unit" (or PMF)
>>>
>>> I like this suggestion! I assume the following would be
>> true -- please
>>> correct where I've got it wrong.
>>>
>>> * The name of this file is
>>> "META-INF/services/javax.jdo.PersistenceManagerFactory"
>>> * This is a text file
>>> * The contents of the file would be the name of the provider's
>>> implementation class of javax.jdo.PersistenceManagerFactory
>>
>> Yes. See a mail by Erik to the lists on 19/01/2007 called
>> "Proposal for
>> Service Discovery". JDOHelper would then have the job of
>> finding all services
>> files of this name ("javax.jdo.PersistenceManagerFactory"),
>> and from the
>> contents finding the relevant PMF to instantiate for a
>> particular PMF name.
Ok.
>>
>>
>> Since this appears to be an extension to JDO and not the
>> simple mapping across
>> of terminology JDO-JPA (being able to read a
>> "persistence.xml"), I'd ask are
>> we just confusing users by having "persistenceUnitName" and
>> "transactionType"
>> for when a JDO impl reads a "persistence.xml", yet here we
>> also have a PMF
>> name (which is the same as a persistence-unit name) for when
>> we use this
>> file.
>>
> This was brought up on the conference call. A "persistence unit"
> is the
> same thing as a "named PMF".
Yes.
> We decided that we won't use the term
> "named PMF" in the specification -- we'll just go with "persistence
> unit". There will be a JPA flavor (already specified) and a
> corresponding JDO flavor (adding a name to a PMF, the getName()
> method).
>
> As far as transaction type, I think they're the same.
There is nothing in JDO 2.0 that corresponds to JPA TransactionType.
We're adding it to JDO 2.1. So there is no ambiguity and no reason I
can think of to create a different name.
Craig
> Craig, can you
> please comment on transaction type?
>
> -matthew
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
RE: [DISCUSS] Named PMF proposal (JDOHelper enhancements)
Posted by Matthew Adams <ma...@xcalia.com>.
Inline...
>> Call it what you want -- I only proposed these names. I
>wouldn't call
>> it persistence.xml, as the contents are not the same as the
>> JPA-specified content. If the persistence.xml is found, its contents
>> are of course interpretable by the JDO implementation
>according to our
>> JPA alignment verbage defined in JDO 2.1.
>
>ok. So a JDO2.1 impl has to understand both "persistence.xml"
>(JPA format) and
>this "jdo.xml" ? No problem if that is the case but just want
>to understand
>what we're specifying here since not everyone was on this conf call.
>
Yes, this is correct. I guess since JPA, which uses the base namespace
"javax.persistence" and calls the file "persistence.xml", then we should
probably call JDO bootstrap file "jdo.xml". Done.
>> >We could use the
>> >same boot idea as JPA and have a
>META-INF/services/javax.jdo.XXX file
>> >defining the PMF(s) available, and it takes the one that
>> >claims it supports
>> >the required "persistence-unit" (or PMF)
>>
>> I like this suggestion! I assume the following would be
>true -- please
>> correct where I've got it wrong.
>>
>> * The name of this file is
>> "META-INF/services/javax.jdo.PersistenceManagerFactory"
>> * This is a text file
>> * The contents of the file would be the name of the provider's
>> implementation class of javax.jdo.PersistenceManagerFactory
>
>Yes. See a mail by Erik to the lists on 19/01/2007 called
>"Proposal for
>Service Discovery". JDOHelper would then have the job of
>finding all services
>files of this name ("javax.jdo.PersistenceManagerFactory"),
>and from the
>contents finding the relevant PMF to instantiate for a
>particular PMF name.
>
>
>Since this appears to be an extension to JDO and not the
>simple mapping across
>of terminology JDO-JPA (being able to read a
>"persistence.xml"), I'd ask are
>we just confusing users by having "persistenceUnitName" and
>"transactionType"
>for when a JDO impl reads a "persistence.xml", yet here we
>also have a PMF
>name (which is the same as a persistence-unit name) for when
>we use this
>file.
>
This was brought up on the conference call. A "persistence unit" is the
same thing as a "named PMF". We decided that we won't use the term
"named PMF" in the specification -- we'll just go with "persistence
unit". There will be a JPA flavor (already specified) and a
corresponding JDO flavor (adding a name to a PMF, the getName() method).
As far as transaction type, I think they're the same. Craig, can you
please comment on transaction type?
-matthew
Re: [DISCUSS] Named PMF proposal (JDOHelper enhancements)
Posted by Andy Jefferson <an...@jpox.org>.
> Call it what you want -- I only proposed these names. I wouldn't call
> it persistence.xml, as the contents are not the same as the
> JPA-specified content. If the persistence.xml is found, its contents
> are of course interpretable by the JDO implementation according to our
> JPA alignment verbage defined in JDO 2.1.
ok. So a JDO2.1 impl has to understand both "persistence.xml" (JPA format) and
this "jdo.xml" ? No problem if that is the case but just want to understand
what we're specifying here since not everyone was on this conf call.
> >2. Why not just use same definition of "persistence.xml" from
> >aforementioned JPA spec ?
> > When JDO2.1 has annotations not everything is
> >always defined in a
> >jdo(/orm/jdoquery) file, so would be nice to have the ability
> >to specify classes, or jars.
>
> Because it's not the same as the persistence.xml. If we're missing the
> ability to specify classes or jars, let's add it!
ok.
> >4. Why do we need "persistence-manager-factory" class="..." ?
>
> Basically, for backward similarity only, not necessarily backward
> compatibility. It was only a suggestion as well, since we could just go
> with a <property name="javax.jdo.PersistenceManagerFactoryClass"
> value="..."/> element. It's just that this property is almost always
> present, so I thought a convenient shortcut would be nice.
ok.
> >We could use the
> >same boot idea as JPA and have a META-INF/services/javax.jdo.XXX file
> >defining the PMF(s) available, and it takes the one that
> >claims it supports
> >the required "persistence-unit" (or PMF)
>
> I like this suggestion! I assume the following would be true -- please
> correct where I've got it wrong.
>
> * The name of this file is
> "META-INF/services/javax.jdo.PersistenceManagerFactory"
> * This is a text file
> * The contents of the file would be the name of the provider's
> implementation class of javax.jdo.PersistenceManagerFactory
Yes. See a mail by Erik to the lists on 19/01/2007 called "Proposal for
Service Discovery". JDOHelper would then have the job of finding all services
files of this name ("javax.jdo.PersistenceManagerFactory"), and from the
contents finding the relevant PMF to instantiate for a particular PMF name.
Since this appears to be an extension to JDO and not the simple mapping across
of terminology JDO-JPA (being able to read a "persistence.xml"), I'd ask are
we just confusing users by having "persistenceUnitName" and "transactionType"
for when a JDO impl reads a "persistence.xml", yet here we also have a PMF
name (which is the same as a persistence-unit name) for when we use this
file.
--
Andy
RE: [DISCUSS] Named PMF proposal (JDOHelper enhancements)
Posted by Matthew Adams <ma...@xcalia.com>.
>1. Why call this file javax.jdo.xml ?, why not jdo.xml ?, or
>even why not
>persistence.xml ?
>
Call it what you want -- I only proposed these names. I wouldn't call
it persistence.xml, as the contents are not the same as the
JPA-specified content. If the persistence.xml is found, its contents
are of course interpretable by the JDO implementation according to our
JPA alignment verbage defined in JDO 2.1.
>2. Why not just use same definition of "persistence.xml" from
>aforementioned
>JPA spec ?
> When JDO2.1 has annotations not everything is
>always defined in a
>jdo(/orm/jdoquery) file, so would be nice to have the ability
>to specify
>classes, or jars.
>
Because it's not the same as the persistence.xml. If we're missing the
ability to specify classes or jars, let's add it!
>3. We could certainly extend the "persistence.xml" concept to
>add on the
>listeners, etc as proposed.
>
Cool, but I'd still like to keep a JDO affinity
("InstanceLifecycleListeners") plus support for the JPA concepts
according to our intended alignment.
>4. Why do we need "persistence-manager-factory" class="..." ?
>
Basically, for backward similarity only, not necessarily backward
compatibility. It was only a suggestion as well, since we could just go
with a <property name="javax.jdo.PersistenceManagerFactoryClass"
value="..."/> element. It's just that this property is almost always
present, so I thought a convenient shortcut would be nice.
>We could use the
>same boot idea as JPA and have a META-INF/services/javax.jdo.XXX file
>defining the PMF(s) available, and it takes the one that
>claims it supports
>the required "persistence-unit" (or PMF)
>
I like this suggestion! I assume the following would be true -- please
correct where I've got it wrong.
* The name of this file is
"META-INF/services/javax.jdo.PersistenceManagerFactory"
* This is a text file
* The contents of the file would be the name of the provider's
implementation class of javax.jdo.PersistenceManagerFactory
* There is a file with the same name as the contents of the file
"META-INF/services/javax.jdo.PersistenceManagerFactory"
* The contents of this file are the same as the proposed content
of javax.jdo.xml (or jdo.xml, or ...) containing the named PMFs.
Thoughts?
-matthew
Re: [DISCUSS] Named PMF proposal (JDOHelper enhancements)
Posted by Andy Jefferson <an...@jpox.org>.
Hi Matthew,
Some comments, or rather questions :-
1. Why call this file javax.jdo.xml ?, why not jdo.xml ?, or even why not
persistence.xml ?
2. Why not just use same definition of "persistence.xml" from aforementioned
JPA spec ? When JDO2.1 has annotations not everything is always defined in a
jdo(/orm/jdoquery) file, so would be nice to have the ability to specify
classes, or jars.
3. We could certainly extend the "persistence.xml" concept to add on the
listeners, etc as proposed.
4. Why do we need "persistence-manager-factory" class="..." ? We could use the
same boot idea as JPA and have a META-INF/services/javax.jdo.XXX file
defining the PMF(s) available, and it takes the one that claims it supports
the required "persistence-unit" (or PMF)
--
Andy
RE: [DISCUSS] Named PMF proposal (JDOHelper enhancements)
Posted by Matthew Adams <ma...@xcalia.com>.
Here is the XSD as a work in progress, in a pre-alpha state. Should we
create a JIRA issue for this? Email seems nonideal for file management,
especially when they're not attached.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://java.sun.com/xml/ns/jdo/jdo-config"
xmlns="http://java.sun.com/xml/ns/jdo/jdo-config"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
version="1.0">
<!-- TODO: Decide if these should be imported, included, or
copy/pasted
<xs:import namespace="http://java.sun.com/xml/ns/jdo/jdo"
schemaLocation="jdo.xsd"/>
<xs:import namespace="http://java.sun.com/xml/ns/jdo/orm"
schemaLocation="orm.xsd"/>
<xs:import namespace="http://java.sun.com/xml/ns/jdo/jdoquery"
schemaLocation="jdoquery.xsd"/>
-->
<xs:element name="jdo-config">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded"
ref="extension"/>
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="persistence-manager-factory">
<xs:complexType>
<xs:choice>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="property">
<xs:complexType>
<xs:attributeGroup ref="attlist.property"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:element name="properties" type="xs:string"/>
</xs:choice>
<xs:attributeGroup
ref="attlist.persistence-manager-factory"/>
</xs:complexType>
</xs:element>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="instance-lifecycle-listener">
<xs:complexType>
<xs:attributeGroup
ref="attlist.instance-lifecycle-listener"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded"
ref="extension"/>
<!-- TODO: include sequences of <jdo [resources=""]>, <orm
[resources=""]>, and <jdoquery [resources=""]> elements here -->
</xs:sequence>
<xs:attributeGroup ref="attlist.jdo-config"/>
</xs:complexType>
</xs:element>
<xs:attributeGroup name="attlist.jdo-config"/>
<xs:attributeGroup name="attlist.persistence-manager-factory">
<xs:attribute name="name"/>
<xs:attribute name="resource"/>
<xs:attribute name="persistence-manager-factory-class"/>
<xs:attribute name="optimistic"/>
<xs:attribute name="retain-values"/>
<xs:attribute name="restore-values"/>
<xs:attribute name="ignore-cache"/>
<xs:attribute name="nontransactional-read"/>
<xs:attribute name="nontransactional-write"/>
<xs:attribute name="multithreaded"/>
<xs:attribute name="connection-driver-name"/>
<xs:attribute name="connection-user-name"/>
<xs:attribute name="connection-password"/>
<xs:attribute name="connection-url"/>
<xs:attribute name="connection-factory-name"/>
<xs:attribute name="connection-factory2-name"/>
<xs:attribute name="mapping"/>
</xs:attributeGroup>
<xs:attributeGroup name="attlist.property">
<xs:attribute name="name"/>
<xs:attribute name="value"/>
</xs:attributeGroup>
<xs:attributeGroup name="attlist.instance-lifecycle-listener">
<xs:attribute name="post-attach"/>
<xs:attribute name="pre-attach"/>
<xs:attribute name="post-clear"/>
<xs:attribute name="pre-clear"/>
<xs:attribute name="post-create"/>
<xs:attribute name="post-delete"/>
<xs:attribute name="pre-delete"/>
<xs:attribute name="post-detach"/>
<xs:attribute name="pre-detach"/>
<xs:attribute name="post-dirty"/>
<xs:attribute name="pre-dirty"/>
<xs:attribute name="post-load"/>
<xs:attribute name="post-store"/>
<xs:attribute name="pre-store"/>
</xs:attributeGroup>
<xs:element name="extension">
<xs:complexType>
<xs:complexContent>
<xs:extension base="any">
<xs:attributeGroup ref="attlist.extension"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:attributeGroup name="attlist.extension">
<xs:attribute name="vendor-name" use="required"/>
<xs:attribute name="key"/>
<xs:attribute name="value"/>
</xs:attributeGroup>
<xs:complexType name="any" mixed="true">
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded"
processContents="skip"/>
</xs:sequence>
</xs:complexType>
</xs:schema>