content/configuring-persistenceunits-in-tests.mdtext

Title: Configuring PersistenceUnits in Tests
<a name="ConfiguringPersistenceUnitsinTests-Overridingthepersistence.xml"></a>
# Overriding the persistence.xml

The most common situation in EJB related testing by far is the need to
alter your persistence.xml for a test environment.

<a name="ConfiguringPersistenceUnitsinTests-Overridingthe<jta-data-source>and<non-jta-data-source>"></a>
## Overriding the jta-data-source and non-jta-data-source

OpenEJB will automatically use the DataSources you have setup in your test
environment, we're pretty good at guessing the right DataSources you intend
even if the names don't match exactly -- or in some cases at all.  If there
is only one DataSource configured, it's very easy for us to guess the
DataSource to use.

This allows you to keep your persistence.xml configured for your production
environment and helps eliminate the need for a "test" persistence.xml
(though we do have that functionality).  A log line will be printed saying
if we had to adjust the DataSources of your persistence.xml.

<a name="ConfiguringPersistenceUnitsinTests-Overridingthepersistence-unit<properties>"></a>
##  Overriding the persistence-unit properties

You can override any property in your test setup via either system
properties or the initial context properties.  The format is:

`<unit-name>.<property>=<value>`

So for example with the following persistence.xml:

    <persistence>
      <persistence-unit name="movie-unit">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <jta-data-source>movieDatabase</jta-data-source>
        <non-jta-data-source>movieDatabaseUnmanaged</non-jta-data-source>
        <properties>
          <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
          <property name="hibernate.max_fetch_depth" value="3"/>
        </properties>
      </persistence-unit>
    </persistence>

    
You can override and add persistence unit properties in your test case.
There are currently no facilities for removing them (if you have a need for
that let us know -- it hasn't really come up so far).

    Properties p = new Properties();
    p.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.openejb.client.LocalInitialContextFactory");

    p.put("movie-unit.hibernate.hbm2ddl.auto", "update");
    p.put("movie-unit.hibernate.dialect", "org.hibernate.dialect.HSQLDialect");

    context = new InitialContext(p);

The overriding order is as follows: 1 = highest, 4 = lowest.
    
1. InitialContext properties
1. jndi.properties from the classpath
1. System properties
1. persistence.xml properties
     
By default there are no overrides in 1-3, so #4 is the only source of
information.  
    
In the above example there would be exactly three properties for the "movie-unit" persistence unit:

  - hibernate.hbm2ddl.auto = update
  - hibernate.max_fetch_depth = 3
  - hibernate.dialect = org.hibernate.dialect.HSQLDialect
    
These properties would be passed by OpenEJB directly to the persistence
provider (in this case Hibernate).  With one exception OpenEJB does not
understand or modify these properties.	Details on that one exception
below.

### Common mistakes

Note that you **must** use the **unit name** as the prefix.  This will not work:

        Properties p = new Properties();
        p.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.openejb.client.LocalInitialContextFactory");

        p.put("hibernate.hbm2ddl.auto", "update");
        p.put("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");

        context = new InitialContext(p);

Currently, only properties that start with the unit name are search and applied.

###  No need to specify a "transaction lookup" property

All vendors have such a property for getting a reference to the container's
TransactionManager and nothing works if this is not set correctly to the
OpenEJB specific class.  To make the lives of users easier, OpenEJB will
take the liberty of setting it for you.

Here are the persistence provider classes we understand and the defaults we
will set for you:

#### Provider org.hibernate.ejb.HibernatePersistence

When using this provider, the *hibernate.transaction.manager_lookup_class*
will be automatically set by OpenEJB to
_org.apache.openejb.hibernate.TransactionManagerLookup_.  If the property
is already set in the persistence unit it will be overwritten if it starts
with the standard "org.hibernate.transaction." prefix.	

Custom lookup implementations will never be overwritten automatically.

#### Provider oracle.toplink.essentials.PersistenceProvider

Or _oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider_.

When using this provider, the *toplink.target-server* will be automatically
set by OpenEJB to _org.apache.openejb.toplink.JTATransactionController_. 
If the property is already set in the persistence unit it will be
overwritten if it starts with the standard "oracle.toplink.transaction."
prefix.  

Custom transaction controller implementations will never be overwritten automatically.

#### Provider org.eclipse.persistence.jpa.PersistenceProvider

Or _org.eclipse.persistence.jpa.osgi.PersistenceProvider_.

When using this provider, the *eclipselink.target-server* will be
automatically set by OpenEJB to
_org.apache.openejb.eclipselink.JTATransactionController_.  If the property
is already set in the persistence unit it will be overwritten if it starts
with the standard "org.eclipse.persistence.transaction." prefix.  

Custom transaction controller implementations will never be overwritten automatically.

#### Provider org.apache.openjpa.persistence.PersistenceProviderImpl

OpenJPA is capable of discovering the correct method for locating the
TransactionManager without the need for users to specify the specific
strategy.  Therefore no specific "magic" is required.