Java EE default datasource

[martin.andersson]

I am coming from a GlassFish 4 background and upgraded my application to JDK 8. However, GF 4 cracked down instantly and won't deploy my application anymore. So I heard WildFly supports JDK 8 and also that WildFly is supposed to be a Java EE 7 compliant application server. However, when deploying to WildFly 8.1.0 CR1, the application server complains and say that my default datasource "is missing". I googled the topic but all I found was bugs reported and then closed. Have I missed something? I've scanned my log file thoroughly and I can see that WildFly register the ExampleDS data source, but he does not register a DefaultDataSource. The Java EE 7 specification (JSR-342) says:

"The Java EE Product Provider must also provide a preconfigured, default data source for use by the application in accessing this database. The Java EE Product Provider must make the default data source accessible to the application under the JNDI name java:comp/DefaultDataSource."

If it is that WildFly doesn't setup this default data source, then I find it a bit obtrusive that WildFly is called a Java EE 7 compliant application server.

[smarlow]

How does your application depend on the DataSource (e.g. referenced from persistence.xml)?  Can you show us the deployment error that you get?  Please include the full exception call stack.  Please include an example of what your persistence.xml contains as well (if you have one).

[emmartins]

Instead of hurting our feelings, can you please provide more info about how you are trying to obtain the default datasource? Thanks in advance.

[martin.andersson]

Eduardo, in what way did I hurt your feelings? If it is my latest remark that I find it "a bit obtrusive" that WildFly is called a Java EE compliant server, I can only say that I'm deeply sorry and that I regret choosing the wrong words. I wanted to express my opinion, which I still hold, that it is missleading the market by calling a product for something it isn't. In my mind, after only having found closed bugs, I thought that a default data source wasn't something the developers had in mind adding.

I don't not want it to sound like a complaint targetting anyone. If anything, I wanted to express a view that we all could participate in, one way or the other.

What I should have done first is to thank you all for your hard work and your belief in the open source community and for your driving spirit of sharing. These are the qualities of people I will remember for my entire life. Therefore, I am glad to call myself a developer for I feel we all seek the truth and we all want to make a positive difference in other people's lives.

I will provide more information as soon as I get the chance. Thank you both Scott and Eduardo for your feedback.

[martin.andersson]

I take the liberty of simplifying names and paths in the upcoming quotes.

Here's a snippet from the log file:

21:09:47,580 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "myApp-war-1.0.0-SNAPSHOT.war" (runtime-name: "myApp-war-1.0.0-SNAPSHOT.war")
21:09:47,989 INFO  [org.jboss.as.jpa] (MSC service thread 1-3) JBAS011401: Read persistence.xml for myapp-jta-pu
21:09:47,990 INFO  [org.jboss.as.jpa] (MSC service thread 1-3) JBAS011401: Read persistence.xml for myapp-resource-local-pu
21:09:48,337 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "myApp-war-1.0.0-SNAPSHOT.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => [
    "jboss.persistenceunit.\"myApp-war-1.0.0-SNAPSHOT.war#myapp-resource-local-pu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.myApp.myApp.DefaultDataSource]",
    "jboss.persistenceunit.\"myApp-war-1.0.0-SNAPSHOT.war#myapp-jta-pu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.myApp.myApp.DefaultDataSource]"
]}
21:09:48,448 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "myApp-war-1.0.0-SNAPSHOT.war" (runtime-name : "myApp-war-1.0.0-SNAPSHOT.war")
21:09:48,449 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.naming.context.java.module.myApp.myApp.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."myApp-war-1.0.0-SNAPSHOT.war#myapp-resource-local-pu".__FIRST_PHASE__, service jboss.persistenceunit."myApp-war-1.0.0-SNAPSHOT.war#myapp-jta-pu".__FIRST_PHASE__] 

21:09:58,530 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015877: Stopped deployment myApp-war-1.0.0-SNAPSHOT.war (runtime-name: myApp-war-1.0.0-SNAPSHOT.war) in 25ms
21:09:58,531 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-6) JBAS015876: Starting deployment of "myApp-war-1.0.0-SNAPSHOT.war" (runtime-name: "myApp-war-1.0.0-SNAPSHOT.war")
21:09:58,617 INFO  [org.jboss.as.jpa] (MSC service thread 1-7) JBAS011401: Read persistence.xml for myapp-jta-pu
21:09:58,618 INFO  [org.jboss.as.jpa] (MSC service thread 1-7) JBAS011401: Read persistence.xml for myapp-resource-local-pu
21:09:58,678 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => [
    "jboss.persistenceunit.\"myApp-war-1.0.0-SNAPSHOT.war#myapp-jta-pu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.myApp.myApp.DefaultDataSource]",
    "jboss.persistenceunit.\"myApp-war-1.0.0-SNAPSHOT.war#myapp-resource-local-pu\".__FIRST_PHASE__ is missing [jboss.naming.context.java.module.myApp.myApp.DefaultDataSource]"
]}
21:09:58,785 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018565: Replaced deployment "myApp-war-1.0.0-SNAPSHOT.war" with deployment "myApp-war-1.0.0-SNAPSHOT.war"
21:09:58,791 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.persistenceunit."myApp-war-1.0.0-SNAPSHOT.war#myapp-jta-pu".__FIRST_PHASE__ (unavailable) dependents: [service jboss.deployment.unit."myApp-war-1.0.0-SNAPSHOT.war".POST_MODULE] 
      service jboss.persistenceunit."myApp-war-1.0.0-SNAPSHOT.war#myapp-resource-local-pu".__FIRST_PHASE__ (unavailable) dependents: [service jboss.deployment.unit."myApp-war-1.0.0-SNAPSHOT.war".POST_MODULE]

My persistence.xml file is put in a EJB/JAR package (META-INF/). The JAR file is in turn put in a WAR file (WEB-INF/lib). There is no other persistence.xml file in the JAR file nor the WAR file. Here's the contents:

<?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="myapp-jta-pu" transaction-type="JTA">
    <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
    <class>somepackage.classes.One</class>
    <class>somepackage.classes.Two</class>
    <class>somepackage.classes.Three</class>
    <exclude-unlisted-classes>true</exclude-unlisted-classes>
    <shared-cache-mode>DISABLE_SELECTIVE</shared-cache-mode>
  </persistence-unit>
  <persistence-unit name="myapp-resource-local-pu" transaction-type="RESOURCE_LOCAL">
    <non-jta-data-source>java:comp/DefaultDataSource</non-jta-data-source>
    <class>somepackage.classes.One</class>
    <class>somepackage.classes.Two</class>
    <class>somepackage.classes.Three</class>
    <exclude-unlisted-classes>true</exclude-unlisted-classes>
    <shared-cache-mode>DISABLE_SELECTIVE</shared-cache-mode>
  </persistence-unit>
</persistence>

A persistence context and a persistence unit is injected like so:

@PersistenceContext(unitName = "myapp-jta-pu")
private EntityManager em;

@PersistenceUnit(unitName = "myapp-resource-local-pu")
private EntityManagerFactory emf;

[smarlow]

Can you try adding the wildfly.jpa.twophasebootstrap hint to the persistence definitions:

<?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="myapp-jta-pu" transaction-type="JTA">

    <jta-data-source>java:comp/DefaultDataSource</jta-data-source>

    <class>somepackage.classes.One</class>

    <class>somepackage.classes.Two</class>

    <class>somepackage.classes.Three</class>

    <exclude-unlisted-classes>true</exclude-unlisted-classes>

    <shared-cache-mode>DISABLE_SELECTIVE</shared-cache-mode>

    <properties>

       <property name="wildfly.jpa.twophasebootstrap" value="false" />

    </properties>

  </persistence-unit>

  <persistence-unit name="myapp-resource-local-pu" transaction-type="RESOURCE_LOCAL">

    <non-jta-data-source>java:comp/DefaultDataSource</non-jta-data-source>

    <class>somepackage.classes.One</class>

    <class>somepackage.classes.Two</class>

    <class>somepackage.classes.Three</class>

    <exclude-unlisted-classes>true</exclude-unlisted-classes>

    <shared-cache-mode>DISABLE_SELECTIVE</shared-cache-mode>

    <properties>

       <property name="wildfly.jpa.twophasebootstrap" value="false" />

    </properties>

  </persistence-unit>

</persistence>

If this helps, as I suspect it will, we can discuss the why after.

[smarlow]

Also created WFLY-3301 for making an improvement so that the wildfly.jpa.twophasebootstrap hint isn't needed.

[akaine]

Wouldn't it be more prudent to define your own datasource instead of the "default" one? Just deploy the driver correspondent to your database and add it with its own name. Don't forget to use the correct prefix (java:jboss/datasources/*). Like this:

<persistence-unit name="myPU" transaction-type="JTA">
     <jta-data-source>java:jboss/datasources/myDS</jta-data-source>
     <properties>
          <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>
          <property name="hibernate.temp.use_jdbc_metadata_defaults" value="false"/>
     </properties>
</persistence-unit>

Works with EJB v3.0 and v3.1 like a charm.

And if you really need to simulate a local database you could always use OpenJPA, though normally you can always define it in jboss/wildfly.

[smarlow]

Also try removing (or comment out) the datasource from the persistence unit definition:

<!--  <jta-data-source>java:comp/DefaultDataSource</jta-data-source>  -->

We should then use the default datasource that is configured in standalone.xml (see default-bindings section).

[martin.andersson]

Scott, both your suggestions worked independently and mixed together. I have other issues now so the app won't deploy but I haven't researched them yet. Thank you so much for your help.

Akaine, I kind of agree with you. During testing though (using Arquillian), I find that it is much easier using the default datasource.

[arjant]

Martin Andersson wrote:

Eduardo, in what way did I hurt your feelings? If it is my latest remark that I find it "a bit obtrusive" that WildFly is called a Java EE compliant server, I can only say that I'm deeply sorry and that I regret choosing the wrong words. I wanted to express my opinion, which I still hold, that it is missleading the market by calling a product for something it isn't.

I somewhat agree with you, but the matter of fact is that none of the Java EE implementations are 100% spec compliant. First and foremost the TCK is to blame here, which obviously didn't contain a test for this specific case. But occasionally there are also cases where the spec isn't entirely clear on something. Ongoing work for the expert groups is to simply clarify existing functionality.

Although from a user perspective perhaps very surprising, various vendors implementing Java EE didn't read in the spec that various kinds of standardized data sources (like the default data source and ones created via the data-source element in e.g. web.xml) should be usable for JPA. As an implementer of the spec you may simply have another view of things and what for you as a user may be incredibly obvious, may not be so obvious to the one reading a fairly abstract spec document.

That's why I think it's much appreciated that people like you actually post about your issues and explain your use case

[emmartins]

This is not the case of WildFly not being spec compliant, the JPA spec says that persistence.xml should omit the datasource when targeting the platform's default datasource, not refer to it through java:comp/DefaultDatasource. The initial post spec quote does not applies to PUs, but I've seen this discussion before, more than once actually, I still don't agree with using a EE component (which the PU is not) scoped jndi name. Anyway, I suggested Scott a small enhancement (WFLY-3301) to overcome this common user mistake (IMHO), which is to look at the value of <jta-data-source/> and <non-jta-data-source/>, and if it's java:comp/DefaultDatasource then ignore the element presence.

Martin, I was obviously not being very serious about the feelings hurt, but also obviously wasn't happy you pointing right away the finger to WildFly wrt spec compliance, something that we worked very hard to achieve, after all you didn't even give a chance to app or server bug. Thanks for the kind words after.

[arjant]

Akaine Harga wrote:

Wouldn't it be more prudent to define your own datasource instead of the "default" one?

That's highly dependent on the use case of course. If it was always more prudent to define a data source yourself then the entire concept of the default data source shouldn't have been introduced, should it?

Eduardo Martins wrote:

This is not the case of WildFly not being spec compliant, the JPA spec says that persistence.xml should omit the datasource when targeting the platform's default datasource, not refer to it through java:comp/DefaultDatasource.

I have to look it up again but I remember it being a bit more subtle. I vaguely remember the JPA spec already had a clause about omitting the datasource before the platform default data source was introduced, and it wasn't really clear if they matched exactly (but as said, have to look it up, maybe I'm mistaken here).

java:comp/DefaultDatasource is indeed a bit nasty. I guess java:global might have been better. Too bad nobody mentioned this when the feature was still under discussion. I'm not sure what the exact idea is behind using java:comp. Are deployers supposed to be able to override the DefaultDatasource per component?

[emmartins]

Correct, all those default bindings should have been in java:global instead, and yes, even if not explicitly mentioned in any spec, my understanding is that a component descriptor may override anything in its own java:comp.

[emmartins]

From JPA 2.1 spec:

5. 8.2.1.5  jta-data-source, non-jta-data-source

   In Java EE environments, the jta-data-source and non-jta-data-source elements are used to specify the JNDI name of the JTA and/or non-JTA data source to be used by the persistence pro- vider. If neither is specified, the deployer must specify a JTA data source at deployment or the default JTA data source must be provided by the container, and a JTA EntityManagerFactory will be created to correspond to it.