WILDFLY/JBOSS: WFLYJPA0061: Persistence unitName was not specified and double persistence unit definitions

 

>PROBLEM

Creating a persistence.xml file having two persistence units caused the following Wildfly’s error message:

Caused by: java.lang.IllegalArgumentException: WFLYJPA0061: Persistence unitName was not specified and there are 2 persistence unit definitions in application deployment deployment “todos.war”. Either change the application deployment to have only one persistence unit definition or specify the unitName for each reference to a persistence unit.

The persistence.xml configuration used was:

 

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.1"
   xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
        http://xmlns.jcp.org/xml/ns/persistence
        http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">
        
    <persistence-unit name="primary">
       <jta-data-source>java:jboss/datasources/TasksJsfQuickstartDS</jta-data-source>
       <properties>
          <!-- Properties for Hibernate -->
          <property name="hibernate.hbm2ddl.auto" value="create-drop" />
          <property name="hibernate.show_sql" value="false" />
       </properties>
    </persistence-unit>

    <persistence-unit name="pgTestoneDS">
       <jta-data-source>java:jboss/datasources/pgTestoneDS</jta-data-source>
       <properties>
<!--           <property name="hibernate.hbm2ddl.auto" value="create-drop" /> -->
<!--           <property name="hibernate.show_sql" value="false" /> -->
       </properties>
    </persistence-unit>

</persistence>

 

>SOLUTION

 

After some failures, I’ve decided to repeat the same configuration but doing things in a different order.
The following order was successful:

1. Refactor the code that concerns the primary persistent-unit (or the initial persistent-unit, whatever the name it has).

2. Create a qualifier for this first persistent-unit.

3. Refactor the DAO layer in order to apply its qualifier where the entity manager is injected.

4. Recompile the project and perform a full deployment.

5. Start the server and test.

6. Stop the server

7. If not successful, fix the code revising from step 1.

8. if successful, add the second persistent-unit to persistence.xml file.

9. Create the database manager class, its qualifier, the entities, and DAO layer always using the respective qualifier for the second persistent-unit to differ from the initial code implemented for the first persistent-unit.

10. Recompile the project and perform a full deployment.

11. Start the server and test.

 

 

 

 

SOURCE CODE

todos_double_units_200506_210948

 

>WHAT NOT TO DO

Do not comment or remove the subsystem JPA policy from standalone.xml file.
I found this solution at some sites, but in this case, was not a good idea.
Check the reasons below.

>WRONG EXAMPLE

Edit $SERVER_INSTALL_DIR\standalone\configuration\standalone.xml file.

Find the following configuration:

 

<subsystem xmlns="urn:jboss:domain:jpa:1.1">
	<jpa default-datasource="" default-extended-persistence-inheritance="DEEP"/>
</subsystem>

Comment the configuration like this (line per line):

 

<!--        <subsystem xmlns="urn:jboss:domain:jpa:1.1">-->
<!--            <jpa default-datasource="" default-extended-persistence-inheritance="DEEP"/>-->
<!--        </subsystem>-->

 

Like this:

 

 

 

>CONCLUSIONS FROM THE WRONG EXAMPLE

When the application starts, it fails to load the entity managers.

 

 

 

>WHY?

Int this subsystem JPA configuration, in the server’s standalone.xml file,  there is the following property:

default-extended-persistence-inheritance
Controls how JPA extended persistence context (XPC) inheritance is performed. ‘DEEP’ shares the extended persistence context at the top bean level. ‘SHALLOW’ the extended persistece context is only shared with the parent bean (never with sibling beans).

from:  wildscribe.github.io/WildFly/11.0/subsystem/jpa/index.html

 

This property is responsible for making available the bean instance, following a criterion.
Check next, what the Wildfly’s documentation tells us about this:

– Extended Persistence Context Inheritance
JPA 2.2 specification section 7.6.3.1
If a stateful session bean instantiates a stateful session bean (executing in the same EJB container instance) which also has such an
extended persistence context with the same synchronization type, the extended persistence context of the first stateful session bean
is inherited by the second stateful session bean and bound to it, and this rule recursively applies independently of whether
transactions are active or not at the point of the creation of the stateful session beans.
If the stateful session beans differ in declared synchronization type, the EJBException is thrown by the container.
If the persistence context has been inherited by any stateful session beans, the container does not close the persistence context
until all such stateful session beans have been removed or otherwise destroyed.

from:  github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_developer-guide/JPA_Reference_Guide.adoc

 

 

>TIP – EXTRA INFORMATION

When commenting, avoid comment format like below — using initial and final comments for all lines:

<!--<subsystem xmlns="urn:jboss:domain:jpa:1.1">
  <jpa default-datasource="" default-extended-persistence-inheritance="DEEP"/>
  </subsystem>-->

 

 

>ENV

Windows 10
Wildfly 18
JEE/CDI/JPA