The most common situation in EJB related testing by far is the need to alter your persistence.xml for a test environment.
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.
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.
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:
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.
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.
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:
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.
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.
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.
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.