I am developing a Java EE 7 application and have a requirement for the application to be deployed onto application servers running either GlassFish 4.0 or WildFly 8.1.0. The issue I've got is GlassFish and WildFly use slightly different formats for JNDI names but I can't see how to make my application compatible with both.
In GlassFish my persistence.xml file references the data source jdbc/myDataSouce, but in WildFly the data source needs to be java:/jdbc/myDataSource.
The same is also true for classes that are annotated with #Resource. In GlassFish the annotation for a class using JavaMail would be #Resource(name = "mail/myMailSession"), but to deploy onto WildFly this would need to be #Resource(name = "java:mail/myMailSession").
I know that I could unpack the EAR and JAR files to manually edit files such as persistence.xml but I can't do that for classes that have been annotated with #Resource.
Is there a way I can allow my complied application to be deployed onto GlassFish and WildFly without maintaining two different versions of the code? I'm assuming the answer probably lies with application specific deployment descriptors but I can't find any examples that cover these two scenarios.
Can anyone point me in the right direction please?
You can modify the Wildfly JNDi names and strip the undesired prefixes from the respective JNDI names to find the least common denominator in both app servers. The following works for me with Glassfish and JBoss AS 7.1. Since I expect Wildfly to be backwards-compatible to JBoss in this regard, I guess it'll work for Wildfly as well.
Persistence
Inject as:
#PersistenceContext(unitName="TestPU")
private EntityManager entityManager;
or via ejb-jar.xml:
<persistence-context-ref>
<persistence-context-ref-name>entityManager</persistence-context-ref-name>
<persistence-unit-name>TestPU</persistence-unit-name>
<injection-target> ... </injection-target>
</persistence-context-ref>
The corresponding persistence.xml:
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="TestPU" transaction-type="JTA">
<jta-data-source>datasources/TestDS</jta-data-source>
<class>org.jeeventstore.persistence.jpa.EventStoreEntry</class>
<properties>
<property name="hibernate.show_sql" value="false"/>
<property name="hibernate.format_sql" value="true"/>
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
<property name="hibernate.connection.charSet" value="UTF-8"/>
<property name="eclipselink.logging.level" value="FINE"/>
<property name="eclipselink.logging.level.sql" value="FINE"/>
<property name="eclipselink.logging.parameters" value="true"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
</properties>
</persistence-unit>
</persistence>
(note the simple jta-data-source JNDI name)
Here's a glassfish-resources.xml file used to specify a Derby database on deployment, a similar setup can be used for MySQL or Postgres.
<resources>
<jdbc-resource pool-name="ArquillianEmbeddedDerbyPool"
jndi-name="datasources/TestDS"/>
<jdbc-connection-pool name="ArquillianEmbeddedDerbyPool"
res-type="javax.sql.DataSource"
datasource-classname="org.apache.derby.jdbc.EmbeddedDataSource"
is-isolation-level-guaranteed="false">
<property name="databaseName" value="target/databases/derby"/>
<property name="createDatabase" value="create"/>
</jdbc-connection-pool>
</resources>
And the settings from the JBoss standalone.xml:
<datasource jta="true" jndi-name="java:/datasources/TestDS" pool-name="TestDS" enabled="true" use-ccm="false">
<connection-url>jdbc:postgresql://localhost/test_db</connection-url>
...
</datasource>
Resources
I have not injected a JavaMail component on Glassfish, but similar to the datasoruce settings, it might be worth a try to strip the "java:" part from the #Resource annotation as well.
#Resource(name = "mail/myMailSession")
and then configure Wildfly such that that the mail resource is available at the "java:mail/myMailSession" JNDI location.
Injection via ejb-jar.xml
Another option is to manually inject the fields via a ejb-jar.xml file, and then use a build tool such as maven to copy either of ejb-jar-glassfish.xml or ejb-jar-wildfly.xml to the desired ejb-jar.xml at assembly time.
In one of our projects we use a mixed approach to avoid the burden with the xml configuration: We configure a small number of "provider" beans via ejb-jar.xml to inject, e.g., the persistence context into a PersistenceContextProvider, and then use CDI to inject the PersistenceContextProvider into the EJBs via #EJB, which are found without further configuration since they reside in the same EAR.
I haven't hit the mail-dilemma just yet. But I've ran into the same problem your having when it comes to data source definition and my solution has been to not setup the data sources using the server's console, but make them deployable together with your archive using the #DataSourceDefinition annotation. Turns out WildFly won't complain about java:app/blabla.. if the data source is setup during deployment!
Here is a real world example for you that works on both GlassFish and WildFly:
https://github.com/martinanderssondotcom/java-ee-concepts/../ArquillianDS.java
Note that the data source JNDI name declared is:
java:app/env/ArquillianDS
And here is the related persistence.xml file (don't mind the name of the file in this repository, the repository represents a test project that build archives during runtime and the app will change the name of the file in the archive to persistence.xml):
https://github.com/MartinanderssonDotcom/java-ee-concepts/../persistence-update.xml
Also note that the persistence unit need a data source located using this JNDI name:
java:app/env/ArquillianDS
This deployment works perfectly fine with both GlassFish and WildFly. I've noted that if we declare the data source during deployment, then we pay the price of not seeing the data source listed anywhere in the admin gui/console. For me, that is a small price to pay in order to have a truly portable application. As an added bonus, I don't have to write lengthy installation/setup instructions. For all my projects, the data source is an intrinsic part of the application and I don't mind having a class file in the archive that represents the data source.
The above data source is using a Java DB (or "Apache Derby" for old school people). As some comments in the ArquillianDS.java file describe: GlassFish has problems using a simple URL connection string combined with Java DB. Hence I resorted to specifying all attributes of the #DataSourceDefinition explicitly. Recently in another project of mine (alas not a public one), I used the same construct of deployment time data source definition but targeting MySQL. Here's that data source definition and it works on both servers:
#DataSourceDefinition(
name = "java:app/env/maLivechatDS",
url = "jdbc:mysql://localhost:3306/malivechat_db?createDatabaseIfNotExist=true&user=root&password",
className = "com.mysql.jdbc.jdbc2.optional.MysqlDataSource"
)
#ManagedBean
public class MySQLDataSource { }
Note that the driver is MysqlDataSource and not MysqlXADataSource. One point in my application uses a rather complex transaction scheme and GlassFish ran into problems if I used the XA-driver. However, the non-XA driver used by my application still work properly with JTA transactions so for me, it was just a cheap trick to get the boat floating. You should probably use the XA-driver.
For JNDI Portability with portable DataSourceDefinition annotation, I test it On payara-5.192, wildfly-17.0.1, tomee-8-M3 and openLiberty-19.0.0.7
#DataSourceDefinition(
name = "java:app/env/jdbc/mysql_app_name",
className = "com.mysql.cj.jdbc.MysqlConnectionPoolDataSource",
url = "jdbc:mysql://localhost:3306/db_name?characterEncoding=utf-8&zeroDateTimeBehavior=CONVERT_TO_NULL&user=root&password=password",
minPoolSize = 1,
properties = {"characterEncoding=utf-8","zeroDateTimeBehavior=CONVERT_TO_NULL"})
I used it with MySQL connector 8.
refer to reference. for wildfly I created a startup bean class for configuration and set the annotation in the startup class.
for openLiberty add in server.xml
<application id="app_name" contextRoot="/app_name" name="app_name" location="../app_name.war" type="war">
<classloader commonLibraryRef="mysql"/>
</application>
<library id="mysql">
<file name="/path_to/mysql-connector-java-8.0.17.jar"/>
</library>
and put the war file in
usr/servers/defaultServer
folder
Related
I am trying to implement a GWT project in IntelliJ Idea 15. I have no problems (at least obvious) with GWT and its superdev mode - I can run an application and play with it. I can do RPC calls.
However, now I am trying to add JPA/Hibernate support to use a database. And here I have troubles. In the project I have a GWT facet (2.6.1), a JPA facet (with hibernate implementation), and a web facet (for web dd). Using Open Module Settings -> Libraries -> New Project Library I have added gwt-servlet.jar, and using maven (its not a maven project, just using the feature of Idea) libraries: c3p0:c3p0:0.9.1.2, org.hibernate:hibernate-entitymanager:5.0.3.Final, org.postgresql:postgresql:9.3-1101-jdbc41 ; that is the configuration.
Using this persistence unit properties (excerpt):
<property name="hibernate.connection.driver_class" value="org.postgresql.Driver"/>
<property name="hibernate.c3p0.min_size" value="5" />
<property name="hibernate.c3p0.max_size" value="20" />
<property name="hibernate.c3p0.timeout" value="300" />
<property name="hibernate.c3p0.max_statements" value="50" />
<property name="hibernate.c3p0.idle_test_period" value="3000" />
In GWT RPC servlet I try to create EntityManager instance:
EntityManagerFactory emf = Persistence.createEntityManagerFactory("ThreatPersistenceUnit");
EntityManager em = emf.createEntityManager();
Query query = em.createQuery("SELECT a FROM Asset a");
...
But when I try to run it in the IDEA using default GWT run configuration (Jetty), I get following exception:
javax.persistence.PersistenceException: Unable to build entity manager factory
caused by
Caused by: java.lang.ClassNotFoundException: Could not load requested class : org.postgresql.Driver
Also, before the exception I get following warning:
WARN: HHH000022: c3p0 properties were encountered, but the c3p0 provider class was not found on the classpath; these properties are going to be ignored.
So it seems the server cannot see both c3p0 and postgre jdbc driver.
I tried to google, the closest problem/solution I found is this SO answer. I have put the libraries both to the project and to the artifact. However, I am not sure what the replier meant by the Jetty lib. Where would I find Jetty installation, if I am using just the GWT's default server?
Plus, what seems quite weird to me is that before I had a similar problem (I dont remember if it was exactly the ClassNotFoundException) with GWT RPC that I was able to resolve by adding a gwt-servlet.jar to the libraries - why then adding these other libraries does not help? At least it seems that it does not have any problems with hibernate, since it provides the warnings and so on.
OK, even though it is a stupid mistake, maybe someday in the future someone else will make it, so for future reference this was the issue:
I had set the SDK and sources version of the project as 1.6; the hibernate and other libraries seem to been compiled in the same or lower version. However, the postgre driver was compiled using a newer version - when I have set the source version to 1.7 and set as an SDK the Java 8 SDK, the program crashed at some different exception (but that was due to my programming error - unrelated). I found this out only after I tried (in total desperation) to create a new object of the driver manually in the code (not to delegate the creation to persistence provider) - then I got the major minor version exception and I knew what is the problem.
Short Version
I've got a Java-project which uses JPA 2.0 with Hibernate 4.3.4. All is fine when I run it inside Eclipse. But when I let Eclipse export a runnable JAR, the trouble begins and the program crashes due to a seemingly missing persistence unit...
javax.persistence.PersistenceException: No Persistence provider for EntityManager named MyDBManager
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:61)
... or seemingly unmapped classes...
3024 Thread-4| FATAL DbManager : DBManager could not load countries from database.
java.lang.IllegalArgumentException: org.hibernate.hql.internal.ast.QuerySyntaxException: Country is not mapped [SELECT x FROM Country x]
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1750)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1683)
at org.hibernate.jpa.spi.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:331)
Background
Depending on the kind of export (extracting vs. packaging vs. copying libraries), I run into different errors which resist solving. The furthest I get is with the last approach, which is also the one I have to choose for license reasons, so let's focus on that one.
In this case the exported JAR fails to look into its persistence.xml. I will specify that later but first some background information...
Folder Structure
some_folder
myproject_lib
myproject.jar
root of my project's package structure
meta-inf
persistence.xml
File persistence.xml
<persistence xmlns="http://java.sun.com/xml/ns/persistence" version="2.0">
<persistence-unit name="MyDBManager" transaction-type="RESOURCE_LOCAL">
<!-- <exclude-unlisted-classes>false</exclude-unlisted-classes> -->
<!-- <class>isi.eload.core.Country</class> -->
<properties>
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver" />
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect" />
<!-- Do not define a connection here - this is done by the DbManager according to the command line arguments -->
<property name="hibernate.id.new_generator_mappings" value="true" />
<!-- <property name="hibernate.archive.autodetection" value="class, hbm" /> -->
</properties>
</persistence-unit>
</persistence>
I played around with the commented lines, once I felt that the xml is actually processed (see below) but that didn't help.
JPA/Hibernate JARs
Essentially the ones from the 4.3.4 Final Release:
antlr-2.7.7
dom4j-1.6.1
hibernate-commons-annotations-4.0.4.Final
hibernate-core-4.3.4.Final
hibernate-entitymanager-4.3.4.Final
hibernate-jpa-2.1-api-1.0.0.Final
jandex-1.1.0.Final
javassist-3.18.1-GA
jboss-logging-3.1.3.GA
jboss-logging-annotations-1.2.0.Beta1
jboss-transaction-api_1.2_spec-1.0.0.Final
.
Failing with persistence.xml
Packaged meta-inf
As I hinted at before, the exported JAR fails to properly process the persistence.xml. When I execute it in the above folder structure, the following exception is thrown:
javax.persistence.PersistenceException: No Persistence provider for EntityManager named MyDBManager
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:61)
This exception is usually thrown when the file was found but the persistence unit name given to Persistence.createEntityManagerFactory does not match any persistence unit declared in the files. But this is definitely not the case here!
I have no good idea, why this exception is thrown.
When I edit the JAR file (though I'm not sure that such tampering is not causing problems on its own) and empty or remove the persistence.xml, the error stays the same.
Another meta-inf
My first response was to copy a meta-inf folder next to the JAR:
myproject_lib
myproject.jar
... unchanged ...
meta-inf
persistence.xml
This seems to work, as an entity manager factory can now be created. But then no Entities are found and I think this is related to the fact that the persistence.xml, which is actually used, is not "on the same class path" as the JAR file.
Is there a link or an idea for how I can fix this? Preferably by forcing the JAR file to use the meta-inf folder which it contains itself.
META-INF needs to be in upper case. If Java is attempting to access the filesystem on Windows (or OS X in that regard) META-INF/persistence.xml will be automatically translated to meta-inf/persistence.xml by the operating system. Once you package it up to a JAR it becomes case sensitive and stops working.
I'm working with spring and hibernate. Currently I have the context config file like this
<bean id="sessionFactory"
class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
<!-- other properties -->
<property name="mappingDirectoryLocations" value="classpath:mappings/" />
</bean>
the *.hbm.xml mappings are in the same project.
Now I plan to pull some entities together with the mappings out, so they can be shared with other projects. The question is, how should I configure the sessionFactory bean to get *.hbm.xml files from the newly created project?
I tried mappingJarLocations but got error saying that the class path is not valid.
Instead of classpath: use classpath*:.
Check What is the difference between "classpath:" and "classpath:/" in Spring XML? for a extended answer on the differences between the 2.
AFASIK, Hibernate looks for mentioned hbm files in all the jars in classpath. You need to mention only the files.
I have several session beans that I have written unit tests for. I have setup Maven to include a persistence.xml in the src/main/resources/META-INF directory that refers to a local MySQL database for development purposes. I have another persistence.xml in src/test/resources/META-INF directory that refers to the embedded Derby database __default. The tests are deployed to an embedded GlassFish 3.1 container.
When I run the tests however, I get the following error:
java.lang.RuntimeException: javax.naming.NamingException: Lookup failed for 'jdbc/mylog'
jdbc/mylog is the MySQL database that the persistence unit in the main directory refers to. It is obviously ignoring the persistence unit in the test directory but I have no clue as to why.
Maven is setting the classpath correctly as far as I can tell, with test-classes before classes and a peek in the actual target/test-classes/META-INF directory reveals that it copied the correct, embedded Derby, persistence unit.
[DEBUG] Test Classpath :
[DEBUG] C:\Users\Laurens\Documents\Projects\Mylog\target\test-classes
[DEBUG] C:\Users\Laurens\Documents\Projects\Mylog\target\classes
[DEBUG] C:\Users\Laurens\.m2\repository\org\eclipse\persistence\eclipselink\2.2.0\eclipselink-2.2.0.jar
[DEBUG] C:\Users\Laurens\.m2\repository\org\eclipse\persistence\javax.persistence\2.0.3\javax.persistence-2.0.3.jar
[DEBUG] C:\Users\Laurens\.m2\repository\org\eclipse\persistence\org.eclipse.persistence.jpa.modelgen.processor\2.2.0\org.eclipse.persistence.jpa.modelgen.processor-2.2.0.jar
[DEBUG] C:\Users\Laurens\.m2\repository\org\glassfish\extras\glassfish-embedded-all\3.1\glassfish-embedded-all-3.1.jar
[DEBUG] C:\Users\Laurens\.m2\repository\javax\javaee-web-api\6.0\javaee-web-api-6.0.jar
[DEBUG] C:\Users\Laurens\.m2\repository\junit\junit\4.8.1\junit-4.8.1.jar
Any hint on how to have GlassFish use the proper persistence unit very much appreciated! Thanks!
When running tests using embedded Glassfish, the JPA provider does not use the classpath displayed on the command-line, before executing the maven-surefire-plugin goal (that is used to run the test phase). Embedded Glassfish deploys the artifacts that are available as part of a test scope, as a ScatteredArchive. This scattered archive is typically created in the java.io.tmpdir directory usually with the name gfembed<a_random_number>tmp, unless the embedded Glassfish configuration specified the location of a Glassfish installation root, and a Glassfish domain.
When the embedded Glassfish domain is prepared with the deployed scattered archive, the files to be deployed are typically copied into an exploded directory that houses all the classes (including all dependencies) required by the application. This directory typically happens to be present in the GF_EMBED_DOMAIN_HOME/applications/<application_name> directory. The persistence.xml files from your src/main/resources/META-INF and src/test/resources/META-INF directories are copied here into the <application-name>/META-INF directory. Needless to state, the one that gets copied last, or the one that doesn't get overwritten is the one that is used by the JPA provider during the tests. This always happens to be the file in src/main/resources/META-INF.
You can overcome this situation in two ways:
1. Using a custom Glassfish domain configuration file
You can specify a domain configuration file (domain.xml) that will contain the datasource definition for jdbc/mylog. This is what I do currently for it is very flexible and the domain configuration file can contain other configurations as well. The config file, needs to specified as part of test setup in the following way:
Map<String, Object> props = new HashMap<String, Object>();
props.put("org.glassfish.ejb.embedded.glassfish.installation.root", "./glassfish-install/glassfish");
container = EJBContainer.createEJBContainer(props);
context = container.getContext();
datasource = (DataSource) context.lookup("jdbc/mylog"); //You can lookup the datasource too, to confirm that your setup is successful.
The afore-mentioned glassfish-install directory and its sub-directory glassfish are present in the Maven project root (and also checked into version control); the glassfish directory must contain a directory structure of domain1/config to represent the directory structure of the Glassfish domain of name domain1. The structure in the project can be seen in the below screenshot. The other related files (the JDBC resource adapter JARs and the like), can be obtained from a Glassfish installation directory, but typically these might also be placed in the correct location by the embedded Glassfish runtime, if configured correctly.
The contents of the Glassfish domain configuration file are different from the default one used by embedded Glassfish, except for the datasource and connection pool configuration (the relevant entries added in my usecase where I perform integration tests, have been posted below):
<domain log-root="${com.sun.aas.instanceRoot}/logs" application-root="${com.sun.aas.instanceRoot}/applications" version="10.0">
<system-applications/>
<applications/>
<resources>
<jdbc-resource pool-name="MyPool" jndi-name="jdbc/mylog"/>
...
<jdbc-connection-pool driver-classname="" datasource-classname="org.apache.derby.jdbc.ClientDataSource" res-type="javax.sql.DataSource" description="" name="MyPool" ping="true">
<property name="User" value="APP"></property>
<property name="RetrieveMessageText" value="true"></property>
<property name="CreateDatabase" value="true"></property>
<property name="ServerName" value="localhost"></property>
<property name="Ssl" value="off"></property>
<property name="SecurityMechanism" value="4"></property>
<property name="TraceFileAppend" value="false"></property>
<property name="TraceLevel" value="-1"></property>
<property name="PortNumber" value="1527"></property>
<property name="LoginTimeout" value="0"></property>
<property name="Password" value="APP"></property>
<property name="databaseName" value="MYDB"></property>
</jdbc-connection-pool>
...
</resources>
<servers>
<server name="server" config-ref="server-config">
<resource-ref ref="jdbc/__TimerPool"/>
<resource-ref ref="jdbc/__default"/>
<resource-ref ref="jdbc/mylog"/>
</server>
</servers>
...
...
The default domain.xml file can be downloaded from the java.net site, and modified, in the event you wish to keep the changes as minimal as possible, instead of copying one from a Glassfish installation.
2. Copying over the persistence.xml files
One can add goals to the Maven POM file, to backup and copy the persistence.xml file from src/test/resources/META-INF to src/main/resources/META-INF, before the test phase. After the test phase is complete, the original is restored. I will not go into details of this, as a similar solution is already discussed in a related StackOverflow question. I did not use this approach for integration tests as I required changes to be done beyond the ones that can be carried in persistence.xml, like creation of a custom realm. I use it for unit-tests however, due to the fact that the JPA provider will fetch the persistence.xml file from target/classes instead of target/test-classes, despite the latter appearing first in the classpath order. If you use Hibernate as your JPA provider, enabling TRACE logging for the org.hibernate.ejb logger (as the Ejb3Configuration class is responsible for performing the lookup) would convince you that file in test-classes will not be picked up.
Note:
Most of the answer assumes Glassfish 3.1 but may hold good for upcoming versions as well.
By "embedded glassfish container", do you mean a maven plugin that runs glassfish for you? The classpath for a maven plugin is different and managed differently than the maven test classpath. You might need to be working with a different classpath.
This answer might sounds silly but I was looking for a way which lets me run those tests from eclipse by Run As -> JUnit Test. This is how I made it:
#BeforeClass
public static void setUp() throws IOException {
Files.copy(new File("target/test-classes/META-INF/persistence.xml"), new File("target/classes/META-INF/persistence.xml"));
// ...
}
I'm just copying the test/persistence.xml to classes/persistence.xml. This works.
Is there a way to reuse a jar with JPA annotated entities in more than one SE applications (as a dependency)? <jar-file> in persistence.xml is not supported in SE environments so is there another way?
Officially (per specification), you have to specify all classes using the class element. Quoting the chapter 6.2.1.6 mapping-file, jar-file, class, exclude-unlisted-classes of the JSR-220:
A list of named managed persistence classes may also be specified instead of, or in addition to, the JAR files and mapping files. Any mapping metadata annotations found on these classes will be processed, or they will be mapped using the mapping annotation defaults. The class element is used to list a managed persistence class. A list of all named managed persistence classes must be specified in Java SE environments to insure portability. Portable Java SE applications should not rely on the other mechanisms described here to specify the managed persistence classes of a persistence unit. Persistence providers may also require that the set of entity classes and classes that are to be managed must be fully enumerated in each of the persistence.xml files in Java SE environments.
Now, if you don't mind being not portable, Hibernate supports using the jar-file element in Java SE (in this case an absolute url is needed, not handy). Hibernate actually also supports auto-detection even in JSE. Much better:
<persistence xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unit name="foo">
<!-- This is required to be spec compliant, Hibernate however supports auto-detection even in JSE. -->
<class>foo.Bar<class>
<properties>
<!-- Scan for annotated classes and Hibernate mapping XML files -->
<property name="hibernate.archive.autodetection" value="class, hbm"/>
...
</properties>
</persistence-unit>
</persistence>
As far as I know, there is no way to get the class scanning for annotations to work in that configuration. You can however explicitly point your persistence.xml file at each entity class.
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unit name="punit">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>java:/myDS</jta-data-source>
<!-- Must be explicit as classes are in separate jar -->
<class>com.foo.Bar</class>
<class>com.foo.Baz</class>
<properties/>
</persistence-unit>
</persistence>
From my experience - It now works.
We are using:
Hibernate3.jar 3.6.0.Final
hibernate-jpa-2.0-api-1.0.0.Final.jar
The < jar-file >file:...< /jar-file > knows how to look for relative paths - and it works both for jar files or directories.
I'm using this ability twice:
with a Jar holding my entities - which is used in several apps. each app has it's own persistence.xml - mainly to provide different ehcache settings.
With Junits when I want all my tests, in all other dependent projects to have a single persistence.xml file that will point to all the entities in the entities project. Then we keep the persistence.xml in the entities project under test/resources/META-INF pointing to the Bin directory of that project:
< jar-file >file:../entities/bin< /jar-file >
This was a problem I ran into. Slightly more preverse as I need to run several jar standalone as well as part of a war deployment.
There are a few hacks out there which seem to revolve around either multiple persistence.xml files and/or some strange-looking attempt at trying to reference the jar file using spring resource loaders (which didn't work for me).
My personal hack is to use spring resource loaders to resolve a resource which is in ALL the entity jars, parse out the URL jar reference and use a Spring persistence unit manager to inject these into the jar-file tag in the virtual persistence.xml
This is round-about way of doing it but avoids having multiple persistence.xml - which is technically invalid.
public class SpringPersistenceUnitManager extends DefaultPersistenceUnitManager implements ApplicationContextAware {
private final Logger log = LoggerFactory.getLogger(getClass());
private ApplicationContext ctx = null;
private String jarLocationPattern;
#Override
protected void postProcessPersistenceUnitInfo(MutablePersistenceUnitInfo pui) {
super.postProcessPersistenceUnitInfo(pui);
try {
Resource[] resources = ctx.getResources("classpath*:applicationContext.xml");
for (Resource res : resources) {
String resJar = resolveJar(res.getURL());
if (!resJar.equals(pui.getPersistenceUnitRootUrl().toString())) {
log.info("Adding " + resJar + " to persistence context");
pui.addJarFileUrl(new URL(resJar));
}
}
}
catch (IOException e) {
log.error("error", e);
}
}
private String resolveJar(URL fileInJar) {
String path = fileInJar.getPath();
return path.substring(0, path.indexOf('!'));
}
and the spring context stuff:
<util:properties id="hibernate.properties" location="classpath:hibernate.properties" />
<bean id="persistenceUnitManager" class="com.rokksoft.blackice.util.SpringPersistenceUnitManager"
p:defaultDataSource-ref="jdbcDataSourcePool"
/>
<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean" lazy-init="true"
p:persistenceUnitManager-ref="persistenceUnitManager"
p:persistenceUnitName="blackicePU"
p:dataSource-ref="jdbcDataSourcePool"
p:jpaProperties-ref="hibernate.properties">
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"/>
</property>
</bean>
You want to filter the jar names ideally though - 3rd party jar could have anything in.