I am trying to understand the following things:
When I make an EJB project and deploys it to Glassfish do I set up JDBC resources/connection pools at the administrator center of Glassfish or do I add all the different properites for username, password etc in the persistence.xml? I don't understand one bit of that.
I do not understand why we have both JDBC resource and JDBC Connection pool either. What is it and what is the difference between them? Could somebody explain me these things or/and provide some good link about the persistence.xml file and the part around it?
It's better to define a JDBC resource rather than putting the information in the persistence.xml. In this way you are going to take advantage of connection pooling. You are going to define the JNDI name you provided for the JDBC resource in the persistence.xml.
What is it and what is the difference between them
Below I pasted some parts of the Glassfish 3.x help. Check it out. It's really helpful
JDBC connection pool
A JDBC connection pool contains a group of JDBC connections that are created when the connection pool is registered
JDBC resource
A Java DataBase Connectivity (JDBC) resource (data source) provides applications with the means of connecting to a database. Typically, the administrator creates a JDBC resource for each database accessed by the applications deployed in a domain; however, more than one JDBC resource can be created for a database.
Applications get a database connection from a connection pool by looking up a data source on the Java Naming and Directory Interface (JNDI) API tree and then requesting a connection. The connection pool associated with the data source provides the connection to the application.
Think of the data source(JDBC) resource as a factory for a facade of some type of data service(Connection Pool). In this case it implicitly gets a connection from the pool and provides it to your application.
An example persistence.xml:
<?xml version="1.0" encoding="UTF-8"?>
<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="WebApplication2PU" transaction-type="JTA">
<jta-data-source>jdbc/sample</jta-data-source>
<exclude-unlisted-classes>false</exclude-unlisted-classes>
<properties/>
</persistence-unit>
</persistence>
This line is the JNDI name I gave to my JDBC resourse:
<jta-data-source>jdbc/sample</jta-data-source>
You dont need to define anything related to the database connection in your persistence.xml this way...just the JNDI name of the resource
When you configure a data source in your application server, all you need to set in persistence.xml is the JNDI name of that data source.
I found this in the book that I read to learn Spring and Hibernate. The book name is Professional Java for Web Applications written by Nicholas S. Williams. I think this will be helpful for many people.
Creating the Persistence Configuration:
To use the entities you create, you must define a persistence unit. Doing so is simple. Create a
persistence.xml file not dissimilar from a deployment descriptor, but with far fewer options
to worry about. The root element of a persistence configuration file is <persistence>. This
element may contain one or more <persistence-unit> elements. No other elements are
within <persistence>. <persistence-unit> has two attributes: name specifies the name of
the persistence unit and transaction-type indicates whether this persistence unit uses Java
Transaction API (JTA) transactions or standard local transactions.
You must specify a name, which is how you locate the persistence unit in code. If not specified,
transaction-type defaults to JTA in a Java EE application server and RESOURCE_LOCAL in a Java
SE environment or simple Servlet container. However, to prevent unexpected behavior it’s best to
always set this value explicitly instead of relying on a default value.
<persistence-unit> contains the following inner elements. None of them are required (so
<persistence-unit> may be empty); however, you must specify whichever elements you use in the
following order:
<description> contains a useful description for this persistence unit. Although it makes
reading the persistence file easier, it has no semantic value.
<provider> specifies the fully qualified class name of the javax.persistence.spi
.PersistenceProvider implementation used for this persistence unit. By default, when you
look up the persistence unit, the API will use the first JPA provider on the classpath. You
can include this element to mandate a specific JPA provider.
You can use either <jta-data-source> or <non-jta-data-source> (but not both) to
use a JNDI DataSource resource. You may use <jta-data-source> only if
transaction-type is JTA; likewise you may use <non-jta-data-source> only
if transaction-type is RESOURCE_LOCAL. Specifying a DataSource causes the persistence
unit to use that DataSource for all entity operations.
<mapping-file> specifies the classpath-relative path to an XML mapping file. If you don’t
specify any <mapping-file>, the provider looks for orm.xml. You may specify multiple
<mapping-file> elements to use multiple mapping files.
You can use one or more <jar-file> elements to specify a JAR file or JAR files that the
JPA provider should scan for mapping-annotated entities. Any #Entity, #Embeddable,
#javax.persistence.MappedSuperclass, or #javax.persistence.Converter classes
found are added to the persistence unit.
You can use one or more <class> elements to indicate specific #Entity, #Embeddable,
#MappedSuperclass, or #Converter classes that should be added to the persistence unit.
You must annotate the class or classes with JPA annotations.
Using <exclude-unlisted-classes /> or <exclude-unlisted-classes>true</exclude-unlisted-classes> indicates that the provider should ignore classes not
specified with <jar-file> or <class>. Omitting <exclude-unlisted-classes> or using
<exclude-unlisted-classes>false</exclude-unlisted-classes> causes the JPA
provider to scan the classpath location of the persistence file for JPA-annotated classes. If
persistence.xml is located in a JAR file, that JAR file (and only that JAR file) is scanned
for classes. If persistence.xml is located in a directory-based classpath location (such as /
WEB-INF/classes), that directory (and only that directory) is scanned for classes. Prior to
Hibernate 4.3.0 and Spring Framework 3.2.5, specifying this element with the value false
was incorrectly interpreted as true.
<shared-cache-mode> indicates how entities are cached in the persistence unit (if the JPA
provider supports caching, which is optional). NONE disables caching, whereas ALL enables
caching for all entities. ENABLE_SELECTIVE means that only entities annotated #javax
.persistence.Cacheable or #Cacheable(true) (or marked as cacheable in orm.xml)
are cached. DISABLE_SELECTIVE results in caching of all entities except those annotated
#Cacheable(false) (or marked as non-cacheable in orm.xml). The default value,
UNSPECIFIED, means that the JPA provider decides what the effective default is. Hibernate
ORM defaults to ENABLE_SELECTIVE, but relying on this is not portable.
<validation-mode> indicates if and how Bean Validation should be applied to entities.
NONE means that Bean Validation is not enabled, whereas CALLBACK makes the provider
validate all entities on insert, update, and delete. AUTO has an effective value of CALLBACK
if a Bean Validation provider exists on the classpath and an effective value of NONE if no
Bean Validation provider exists on the classpath. If you enable validation, the JPA provider
configures a new Validator to validate your entities. If you have configured a special
Spring Framework Validator with your custom localized error codes, the JPA provider
ignores it. As such, it’s best to set the validation mode to NONE and use Bean Validation
before your persistence layer is invoked.
<properties> provides a way to specify other JPA properties, including standard JPA
properties (such as JDBC connection string, username, and password, or schema generation
settings) as well as provider-specific properties (such as Hibernate settings). You specify
one or more properties using nested elements, each with a name and value
attribute.
Nicholas S. Williams, Professional Java for Web Applications, (Indianapolis, Indiana: John Wiley & Sons, Inc., 2014), pg 584-585
Related
Sorry for the long back story but I wanted to give a good idea of why we're doing what we're doing.
Our application currently uses Hibernate 3.6 and we wish to upgrade to Hibernate 4.3.
The application was specifically written to avoid using persistence.xml to configure JPA and create the EntityManagerFactory and instead uses Hibernate's Ejb3Configuration class like this (example):
Properties properties = new Properties();
properties.put("javax.persistence.provider", "org.hibernate.ejb.HibernatePersistence");
properties.put("javax.persistence.transactionType", "RESOURCE_LOCAL");
properties.put("hibernate.dialect", "org.hibernate.dialect.Oracle10gDialect");
properties.put("hibernate.show_sql", "false");
properties.put("hibernate.format_sql", "true");
Ejb3Configuration cfg = new Ejb3Configuration();
cfg.addProperties(properties);
DataSource dataSource = dataSourceProvider.get();
cfg.setDataSource(dataSource);
//add the annotated classes
cfg.addAnnotatedClass(SomePersistentObject.class);
EntityManagerFactory factory = cfg.buildEntityManagerFactory();
The reason we do it this way is because we have a web app (war file) deployed to Tomcat that provides "core" functionality. Then, we install what we call "client bundles" which are jar files in the exploded /WEB-INF/lib directory. The "client bundles" contain overrides to the existing "core" behavior of the web app. This allows us to service multiple clients, each with various customizations from the "core" behavior, in one instance of the web app. We know which client bundle to use based on the domain or subdomain of the incoming HTTP request.
Each client bundle always gets its own database instance, and thus each client bundle defines its own EntityManagerFactory. The schemas are almost identical, although client bundles can add new persistent classes if needed.
So, the reason we do JPA configuration in Java is so that each client bundle extend the "core" classes and add their own entity classes. Java is great for inheritance while XML stinks. If we have to configure via XML, then each client bundle would need to copy the core's persistence.xml and update it from there. I would much rather use inheritance over copy/paste.
I think we have a pretty valid use case for preferring JPA configuration via Java rather than XML.
My question: Does Hibernate 4.3 allow this in any way? If so, how can I go about it?
If not, does anybody have any suggestions on how to make my above scenario as easy as possible while being stuck with XML configuration?
Can multiple jar files within a single web app contain /META-INF/persistence.xml files, or do multiple persistence units need to be defined another way?
Thank you!!!
-Ryan
I overcame the problem by dynamically writing a new persistence.xml file to the web app's classpath, before JPA is bootstrapped.
When the web app starts up, the JPA configuration for all the client bundles is read, and then a single persistence.xml file is written to the classpath. Each client bundle gets its own entry as a persistence-unit within persistence.xml.
Then, after the new persistence.xml is written, JPA is bootstrapped. JPA doesn't know or care, obviously, that the persistence.xml file was written dynamically.
It seems a little like a hack but I couldn't figure out any other way to do it. One nice benefit is that it keeps me away from Hibernate specific APIs, so if I ever want to switch to something like DataNucleus as the JPA provider I will have the flexibility to do so.
Is there a way to set the EclipseLink properties (e.g. target database) in a place different from persistence.xml?
Rational: I have a JPA module defining the data structure and containing persistence.xml. The module might be used with different target databases. In a Java SE application one can set the eclipse link properties programmatically upon creation of EntityManagerFactory. However, when the JPA module is packaged in an EAR for the Glassfish application server the target database must be defined in persistence.xml ... or is there another way?
You can use a RESOURCE_LOCAL persistence unit and access it the same way through EntityManagerFactory.
Where is the list of the names I can use in the property elements in the persistence.xml file?
<property name="eclipselink." value="" />
and since JPA 2.0
<property name="javax.persistence." value="" />
Tried to search but I couldn't find anything.
Here are the list of the standard properties as refer from here:
8.2.1.9 properties
The properties element is used to specify both standard and vendor-specific properties and hints
that apply to the persistence unit and its entity manager factory configuration.
The following properties and hints defined by this specification are intended for use in both Java EE and
Java SE environments:
javax.persistence.lock.timeout — value in milliseconds for
pessimistic lock timeout. This is a hint only.
javax.persistence.query.timeout — value in milliseconds for query
timeout. This is a hint only.
javax.persistence.validation.group.pre-persist— groups that are
targeted for validation upon the pre-persist event (overrides the
default behavior).
javax.persistence.validation.group.pre-update— groups that are
targeted for validation upon the pre-update event (overrides the
default behavior).
javax.persistence.validation.group.pre-remove— groups that are
targeted for validation upon the pre-remove event (overrides the
default behavior).
The following properties defined by this specification are intended for use in Java SE environments.
javax.persistence.jdbc.driver — fully qualified name of the driver
class
javax.persistence.jdbc.url — driver-specific URL
javax.persistence.jdbc.user — username used by database connection
javax.persistence.jdbc.password — password for database connection
validation
While vendor specific properties, you need refer to their documentation. For eclipse link, you can refer to here.
We have to rename persistence.xml to fool WebSphere 7 not to use its built-in OpenJPA.
It is pretty easy to do when you use Spring, you just instruct its entity manager factory to use another location for persistence.xml:
<property name="persistenceXmlLocation" value="META-INF/persistence-xxx.xml"/>
But now we want to use plain Hibernate/JPA without Spring, and couldn't find any way to specify the alternate persistence.xml location.
JPA2 spec doesn't say anything about it...
Any clues? Is it possible to instruct Hibernate to use a renamed persistence.xml?
======
It appears that it is NOT POSSIBLE to make Hibernate read a renamed persistence.xml file.
And not necessary in my case.
As far as I know, it's not possible to change the location of the persistence.xml file.
Also take a look at this document: Alternate JPA Providers in WebSphere Application Server, it seems like you should be able to use Hibernate as JPA provider by specifying it in the persistence.xml file, and embedding the required jars in your application.
Make sure your persistence.xml is specifying Hibernate as JPA provider:
<persistence>
<persistence-unit name="myapp">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
You should also be able to achieve this by creating a shared library and using it to configure WebSphere to use an alternative persistence provider.
Here you can find how to do it: Configuring the Java Persistence API (JPA) default persistence provider
EDIT
Given the information in the comments in this answer, it seems the problem can be solved by adding these properties in persistence.xml, as indicated in this post Websphere EntityManagerFactory creation problem:
<property name="hibernate.transaction.manager_lookup_class"
value="org.hibernate.transaction.WebSphereExtendedJTATransactionLookup" />
<property name="hibernate.transaction.factory_class"
value="org.hibernate.transaction.CMTTransactionFactory" />
This same information is also provided in the Alternate JPA Providers in WebSphere Application Server document.
the persistence.xml should exist in a META-INF directory, usually packaged alongside a jar file that contains your entity classes. What I do is I have the entity clases in a seperate project under eclipse, with a META-INF directory that contains the persistence.xml, package this a jar file, and include it in the applications project dependencies (ie. WEB-INF/lib), or, deploy it straight to the app server.
I want to know that how can I do two phase commit transaction by using Java EE5...I am using EJB with JPA which has hibernate configured with MySql. I just want to use JAVA EE specification for transaction not using hibernate or JDBC specific object....
All you need to do, to ensure that JTA transactions are used to perform all transactional work in JPA, is to specify that the Persistence Unit type is JTA, and designate a JTA datasource for use by the JPA provider. Your persistence.xml file would have contents similar to the following:
<persistence version="1.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_1_0.xsd">
<!-- Specifies the type of the entity managers used by the persistence unit,
as a JTA entity manager -->
<persistence-unit name="example-pu" transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<!-- Specifies a JTA datasource for use by the JPA provider.
All connections obtained by the JPA provider for this persistence unit
will be from this datasource -->
<jta-data-source>jdbc/myDS</jta-data-source>
...
</persistence-unit>
</persistence>
Additionally, you must ensure that the datasource defined in the jta-data-source attribute, does not employ optimizations like allowing local transactions. In simpler words, all transactions involving the said datasource must be XA transactions, or the datasource must be an XA datasource without any support for local transactions.
Note that merely specifiying a JTA data source is not sufficient. You must define the persistence unit as one requiring the use of JTA entity managers, as an undefined value for the transaction-type attribute, depends on the environment in which the JPA provider operates. If the provider operates in a Java EE environment, JTA entity managers will be created, where as RESOURCE_LOCAL entity managers will be created in a Java SE environment.
Also, note that, if you specify the transaction-type as RESOURCE_LOCAL, then in a Java EE environment, the JPA provider will ignore the jta-data-source value, and will instead rely on the non-jta-data-source value for creating connections.