I'm using EclipseLink as my JPA implementation. Our project has a directory where we keep all of our config files, and I would like to store my persistence.xml file in the config directory, but cannot find any way to tell createEntityManagerFactory to look there to find the persistence-unit.
It doesn't answer your question directly, but if you want to do it in order to externalize configuration of the application, I think the best approach would be to extract all configurable properties (such as connection settings, etc) into a separate properties file and pass them to createEntityManagerFactory() as a Map (also note that you can override properties from persistence.xml this way).
Then your persistence.xml will contain only non-configurable settings (such as a list of persistent classes, etc), i. e. it won't make sense to change these properties without rebuilding the whole application, and you can leave it in its default location.
You can achieve this by using spring-orm LocalContainerEntityManagerFactory (you don't need to use all the spring context stuff if you don't want to).
LocalContainerEntityManagerFactory lcemf = new LocalContainerEntityManagerFactory ();
lcemf.setPersistenceUnitName("some_pu");
lcemf.setpersistenceXmlLocation("file:/data/config.xml");
EntityManagerFactory emf = lcemf.createNativeEntityManagerFactory();
you can also ignore the xml once and for all, and configure all in code by using the LocalContainerEntityManagerFactory (see setPackagesToScan).
persistence.xml must always be present within META-INF directory in the classpath. More on where should META-INF be present for different types of java applications can be found here.
Persistence units are defined by the persistence.xml configuration file. The JAR file or directory whose META-INF directory contains persistence.xml is called the root of the persistence unit. The scope of the persistence unit is determined by the persistence unit’s root.
Each persistence unit must be identified with a name that is unique to the persistence unit’s scope.
Persistent units can be packaged as part of a WAR or EJB JAR file, or can be packaged as a JAR file that can then be included in an WAR or EAR file.
If you package the persistent unit as a set of classes in an EJB JAR file, persistence.xml should be put in the EJB JAR’s META-INF directory.
If you package the persistence unit as a set of classes in a WAR file, persistence.xml should be located in the WAR file’s WEB-INF/classes/META-INF directory.
Related
I am a new OpenJPA 2.2.2 user. I noticed that the database configuration has to be defined in META-INF/persistence.xml. This sounds to be too inflexible. Moreover, I found from the OpenJPA 2.2.2 documentation:
The OpenJPA runtime includes a comprehensive system of configuration defaults and overrides:
OpenJPA first looks for an optional openjpa.xml resource. OpenJPA searches for this resource in each top-level directory of your CLASSPATH. OpenJPA will also find the resource if you place it within a META-INF directory in any top-level directory of the CLASSPATH. The openjpa.xml resource contains property settings in JPA's XML format.
You can customize the name or location of the above resource by specifying the correct resource path in the openjpa.properties System property.
On base the introduction above, it seems that the database configuration file name is only possible to be persistence.xml. Moreover, I tried to place it in the top-level directory of my CLASSPATH, i.e., not inside the META-INF directory, it didn't work at all! Is there is any way to define this database persistence xml more flexibly, say in somewhere else than META-INF and with other name than persistence.xml?
First, there is no replacement for persistence.xml (p.xml for short). This is needed no matter what. Furthermore, the location of this file is clearly defined in the JPA specification (e.g. see "8.2 Persistence Unit Packaging" in JPA 2.0 spec). You MUST follow those rules on packaging. OpenJPA first and foremost follows the rules of the spec in regards to this file and its settings. No JPA provider is going to ignore the rules w.r.t p.xml file.
The section of text you copy/pasted is from here in the OpenJPA documentation:
http://openjpa.apache.org/builds/2.2.2/apache-openjpa/docs/manual#ref_guide_conf_specify
As you can see, this section describes an optional file named openjpa.xml. This file does not replace a p.xml file! It adds to it. And as the documentation states, it is simply used to add properties. That is, you can not define your persistence unit here, the only thing you can define are properties (i.e. ). If you define a persistence unit here, it will not be used. As an example, lets look at this openjpa.xml file:
<?xml version="1.0"?>
<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="">
<properties>
<property name="openjpa.jdbc.Schema" value="MySchema" />
<property name="openjpa.jdbc.DBDictionary" value="db2" />
</properties>
</persistence-unit>
This file defines two properties. Notice that the persistence-unit name is blank. That is intentional because, as I mentioned above, we can't define a persistence unit in this file. Finally, you can place this file in the META-INF on your classpath, as mentioned in the documentation. If you put this at the same spot as your p.xml file it will be found. As an example, in my JSE JUnit test, I place it on my hard drive in the directory e:/openjpaConfig/META-INF/openjpa.xml. I then put a classpath entry in my JUnit test to point to the directory e:/openjpaConfig. The classpath could point to a jar which contains this file in its META-INF directory. In a Java EE environment, you could place the file in a .jar file and place the .jar file in the lib directory of an ear.
I have a java-ee web application that uses a persistence unit that is packaged as a jar dependency (Entity classes, EJB repositories, persistence.xml).
In order to get some acceptance tests running for the web application i need to override a property in the packaged persistence.xml. To be specific i need to disable the by default active eclipselink shared object cache by setting the following property.
<property name="eclipselink.cache.shared.default" value="false"/>
This is necessary because the acceptance tests are directly prepare/cleanup the database with dbunit. These modifications will put the eclipselink cache in a stale state (because the persistence unit is not involved in these modifications).
Is there a way in java-ee (or glassfish specific) to override properties in a persistence.xml that is located in a jar (starting from the web application war file, that is deployed when running my tests)?
There may be other ways, for example building the jar dependency specific for a test deployment, but this route seems complicated to me for only override one property in my persistence.xml.
You can pass a properties map to Persistence.createEntityManagerFactory(). To do this you must manage your persistence context yourself (will not be able to inject it).
Another option is to set the property as a Java system property (-D=), this will not override an existing property in the persistence.xml, but with work if the property is not in the persistence.xml.
Another option is to put a SessionCustomizer or a SessionTuner in your persistence.xml to allow your own code to modify the configuration at runtime.
**EntityManagerFactory factory=Persistence.getEnityManagerFactory(???);**
In specification they are explained in the context of EJBs.But i am not understanding the actual possible locations of persistence.xml in a web archive.
The persistence.xml must always be in the META-INF directory on the classpath. Normally it will be inside a jar that is on the classpath, such as a jar in /WEB-INF/lib/ in your war file.
using Eclipse Helios, and the Spring Source Tool Suite 2.8.1.201111221000-RELEASE, having two Eclipse projects with a Spring nature added, the second depending on the first - is there a way to add Spring bean configuration files from both projects to the "Spring/Bean Support" configuration of the second project?
In detail, say
project A builds some a.jar, containing some module.xml file, declaring some Spring beans implemented in A.
project B builds some b.jar, containing some application.xml file, declaring the beans implemented in B
B's spring configuration references some beans which are declared in A's configuration
application.xml does not import module.xml, instead, at runtime an ClassPathXmlApplicationContext is created which loads (all) configurations files from the classpath which match a certain pattern (something like "classpath:application.xml","classpath*:module.xml")
B's spring nature is configured to use application.xml as config file (Project properties => Spring => Beans Support => Config Files)
What I want to do is to tell STS that B's spring configuration consists not only of B's application.xml, but also of A's module.xml. If A is not part of the workspace, but a.jar is located in my Maven repo, with B declared to depend on that artifact, I can add the module.xml config file to B's spring configuration. If, however, A is part of the workspace, referencing its module.xml does not seem to be possible.
Do I miss something?
Thanks
Ah, I did miss something! You can't add module.xml to B's "Spring / Beans Support / Config Files" list - but when you edit a particular Config Set (second tab page), then - surprise! - all of module A's config files are available, too.
works like a charm ...
We are going from a single WAR to multiple WARs to be repackaged within an EAR file in JBoss. I would like to be able to do the following:
Move common libraries to under the root of the new EAR so that they don't have to be duplicated within each of the WARs (I suppose under $EAR_ROOT/lib?).
Move the *-ds.xml file from under $JBOSS_HOME/server//deploy to under the EAR so that the datasource is scoped to the application (at least from a packaging standpoint - I realize there is no preventing a JNDI lookup from other WAR, that's okay).
Repackage the Hibernate DAOs and dependencies to a new to-be-shared JAR file and put them in the common location as well (to be shared by both the WARs).
I have some sense on what needs to happen but could use some help so that I don't have to create all of this structure and the related Ant/Maven targets/goals from scratch. For instance, should the datasource file be referenced in jboss-app.xml or in application.xml directly?
There seem to be multiple ways of skinning this cat and I am looking for a nice, clean example to do this (in the interest of not having to reinvent the wheel).
Use JBoss Developer Studio, it does all that for you