On Dec 12, 2007, at 9:16 PM, Alexander Saint Croix wrote:
Thanks for the fast response, David.
The ability to remove the following four properties is very helpful
and a
great start:
Namely the following:
javax.persistence.provider
javax.persistence.transactionType
javax.persistence.jtaDataSource
javax.persistence.nonJtaDataSource
While packaging up my component beans, I'd rather not specify the
persistence provider from inside the component JAR. If someone
wanted to
use my beans with a different persistence provider they should be able
to--that's what these component JARs are designed for. So, the plan
at the
moment is to write OpenJPA-tailored persistence.xml files, and in
the future
if someone wants to use another PP, I'll have to ship JARs with that
one
line of code different in the XML file.
Just seems off. There should be some way to override that at
least. That
would make packaging these component JARs much more straight-forward
for me.
Maybe I wasn't clear enough. The above properties are specified on a
server level and supply the defaults for all apps when the leave out
any of the following elements from their xml (use of ${} show for
illustrative purposes):
<persistence-unit name="my-unit" transaction-type="$
{javax.persistence.transactionType}">
<provider>${javax.persistence.provider}</provider>
<jta-data-source>${javax.persistence.jtaDataSource}</jta-data-
source>
<non-jta-data-source>${javax.persistence.nonJtaDataSource}</
non-jta-data-source>
</persistence>
Strictly speaking this all you *must* supply in your persistence.xml:
<persistence xmlns="http://java.sun.com/xml/ns/persistence";
version="1.0">
<persistence-unit name="my-unit"/>
</persistence>
... along with the following two properties at the server level:
javax.persistence.jtaDataSource
javax.persistence.nonJtaDataSource
We have a file called conf/system.properties you can use to make
declaring system properties easier in a standalone server. For
embedded environments you're welcome to just add them via
System.setProperty() or even pass them in as parameters to "new
InitialContext(props)".
While fully defining persistence units at the OpenEJB level would be
great,
some sort of override function might be better. "Configuration
shadowing",
or some such.
You don't have to fully define anything in OpenEJB, ever. :)
All of our configuration works on an override basis so you only have
to specify what you want to be different. For example if you took
your openejb.xml file and deleted all the properties from every
Container, Resource, etc., it would still work.
The default values for absolutely everything configurable via an
openejb.xml are declared in xml files that we pack in our jars. When
you declare something via an openejb.xml file, we go find the
"template" that will provide the defaults, we then override them with
the values you supplied via your openejb.xml, then we override again
with any values you supplied via system properies (the format of that
is <component-id>.<property-name>=<property-value>). The result is
then "instantiated" and becomes a real running component (e.g.
Container, Resource, etc.).
Strictly speaking you really don't need to declare anything via your
openejb.xml, namely containers, as we will create them for you as
needed. You really only need to declare what you intend to override.
This is one of the ways we achieve embedded testing so flawlessly.
We also have tool you can use that will print out a fully canonical
version of your running configuration so you can see one big flat list
of everything that exists and what its properties are. See http://openejb.apache.org/3.0/configuration-properties.html
-David
