You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 30, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 30, 2019. It is now read-only.
JPA persistence.xml should integrate with @DataSourceDefinition and web.xml data-source definition #30
Datasources defined via @DataSourceDefinition allow @resource injection of DataSource objects into application code. However, these data-sources are not integrated with the persistence.xml JPA configuration file. And attempted use of the custom defined DataSource in persistence.xml will result in deployment failure. The EE spec allow for interop between these features:
For a datasource definition:
@DataSourceDefinition(
url = "jdbc:h2:mem:",
className = "org.h2.jdbcx.JdbcDataSource",
name = "java:global/jdbc/h2db",
user = "sa",
password = "")
If the server happens to be Glassfish, remember that due to a big bug in that you have to copy the JDBC driver to some installation directory of Glassfish itself. See GLASSFISH-19451
arjan_t said:
There's is definitely something fishy here. Historically this has failed more often and if I'm not misinterpreting things some vendors at least gave (me) the impression that they thought this didn't needed to be supported.
I think the spec should explicitly say that @DataSourceDefinition and web.xml's data-source definition can be used in persistence.xml and add a TCK test that checks that this is indeed possible for a given implementation.
lincolnbaxter said:
When speaking to the various people in charge of JPA integration in these servers, I got the overall impression that they did not believe the spec required this, which is why it does not work on most servers. Thus I moved to file a spec issue that would cause people to do the right thing
Activity
glassfishrobot commentedon Sep 9, 2013
Reported by lincolnbaxter
glassfishrobot commentedon Sep 9, 2013
reza_rahman said:
I think this is a bug unrelated to the spec. I have this use case working fine: https://java.net/projects/cargotracker/pages/Home.
glassfishrobot commentedon Sep 12, 2013
kithouna said:
This is definitely a bug with whatever server OP is using.
See http://henk53.wordpress.com/2012/06/30/the-state-of-datasourcedefinition-in-java-ee + http://henk53.wordpress.com/2012/04/15/jsf2-primefaces3-ejb3-jpa2-integration-project/#step10 and http://jdevelopment.nl/open-source/java-ee-kickoff-app for two other working cases.
If the server happens to be Glassfish, remember that due to a big bug in that you have to copy the JDBC driver to some installation directory of Glassfish itself. See GLASSFISH-19451
glassfishrobot commentedon Jan 8, 2014
arjan_t said:
There's is definitely something fishy here. Historically this has failed more often and if I'm not misinterpreting things some vendors at least gave (me) the impression that they thought this didn't needed to be supported.
For the current crop of Java EE 7 servers it again fails. See WildFly issue https://issues.jboss.org/browse/WFLY-2727 and GlassFish issue GLASSFISH-20944
I think the spec should explicitly say that @DataSourceDefinition and web.xml's data-source definition can be used in persistence.xml and add a TCK test that checks that this is indeed possible for a given implementation.
glassfishrobot commentedon Jan 9, 2014
arjan_t said:
For the JPA side of this issue see JPA_SPEC-70
glassfishrobot commentedon Apr 10, 2014
lincolnbaxter said:
When speaking to the various people in charge of JPA integration in these servers, I got the overall impression that they did not believe the spec required this, which is why it does not work on most servers. Thus I moved to file a spec issue that would cause people to do the right thing
glassfishrobot commentedon Apr 15, 2014
ldemichiel said:
The spec does require this. We'll make sure that this is clearer in the future, and add a TCK test for it.
glassfishrobot commentedon Mar 13, 2016
arjan_t said:
@ldemichiel
We're now almost 2 years later and just wondering, has this TCK test already been added?
glassfishrobot commentedon Apr 25, 2017
This issue was imported from java.net JIRA JAVAEE_SPEC-30
arjantijms commentedon Aug 13, 2018
This time it's more than 2 years later. Maybe if/when the TCK gets transferred we'll finally be able to see if that TCK test was ever added or not.