tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Alternatives to specifying persistence provider in component jars?
Date Thu, 13 Dec 2007 06:59:50 GMT

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="$ 

Strictly speaking this all you *must* supply in your persistence.xml:

   <persistence xmlns=""  
      <persistence-unit name="my-unit"/>

... along with the following two properties at the server level:


We have a file called conf/ 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  

> 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


View raw message