Persistence Unit not loaded WildFly 24 (Bootable Jar)

[Linda Janse van Rensburg]

Wildfly 24.0.1

Bootable Jar (wildfly-jar-maven-plugin) 5.0.2.Final

 

Also note, the specific code was working as expected in Thorntail, only with the migration to WildFly Bootable Jar the problem occurred.

 

The below I’ve tested with various different scenarios(schedule the ManagedScheduledExecutorService from the servlet, from the EJB, from a POJO class that was invoked by the EJB, from a POJO class that was invoked by the servlet) the outcome always the same:

 

[org.hibernate.jpa.boot.internal.PersistenceXmlParser] (EE-ManagedScheduledExecutorService-TestAppScheduler-Thread-2) HHH000318: Could not find any META-INF/persistence.xml file in the classpath

za.co.absa.esf.exceptions.SystemException: No Persistence provider for EntityManager named XOB_LOCAL_PU: Exception Msg: No Persistence provider for EntityManager named XOB_LOCAL_PU

 

This happens if you access the specific Persistence Unit for the first time (only) in an EE concurrency Utility.

For example:

Maven project – WAR only

 

Persistence.xml location: \src\main\resources\META-INF\

 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<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"> <!-- Defaults to transaction-type="JTA" -->

    <jta-data-source>java:jboss/datasources/testJTADS</jta-data-source>

    <class>za.co.absa.test.function.dao.jpa.Function</class>

    <properties>

               <property name="hibernate.default_schema" value="test"/>

               <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQL9Dialect"/>

    </properties>

  </persistence-unit>

 

  <persistence-unit name="nonjta" transaction-type="RESOURCE_LOCAL">

    <non-jta-data-source>java:jboss/datasources/testDS</non-jta-data-source>

    <class>za.co.absa.test.function.dao.jpa.Function</class>

    <properties>

               <property name="hibernate.default_schema" value="test"/>

               <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQL9Dialect"/>

    </properties>

  </persistence-unit>

</persistence>

 

Datasource configurations:

 # ************************************************************************************************

# PostgreSQL datasource configurations

# ************************************************************************************************

/subsystem=datasources/jdbc-driver=postgresql:add(driver-name=postgresql,driver-module-name=org.postgresql,driver-class-name=org.postgresql.Driver)

data-source add \

        --jndi-name=java:jboss/datasources/testJTADS \

        --name=testJTADS \

        --connection-url=jdbc:postgresql://localhost:5432/testdb \

        --driver-name=postgresql \

        --security-domain=passw \

        --min-pool-size=1 \

        --max-pool-size=10 \

        --transaction-isolation=TRANSACTION_READ_COMMITTED \

        --idle-timeout-minutes=1 \

        --blocking-timeout-wait-millis=5000 \

        --jta=true \

        --prepared-statements-cache-size=10 \

        --flush-strategy=EntirePool \

        --exception-sorter-class-name=za.co.test.CustomPostgreSQLExceptionSorter

 

data-source add \

        --jndi-name=java:jboss/datasources/testDS \

        --name=testDS \

        --connection-url=jdbc:postgresql://localhost:5432/testdb \

        --driver-name=postgresql \

        --security-domain=passw \

        --min-pool-size=1 \

        --max-pool-size=10 \

        --transaction-isolation=TRANSACTION_READ_COMMITTED \

        --idle-timeout-minutes=1 \

        --blocking-timeout-wait-millis=5000 \

        --jta=false \

        --prepared-statements-cache-size=10 \

        --flush-strategy=EntirePool \

        --exception-sorter-class-name=za.co.test.CustomPostgreSQLExceptionSorter

 

My TestServlet schedules the ManagedExecutorService.

 managedScheduledES.schedule(task, trigger);

 

Trigger – runs every 2 minutes. Task instanciates the DAO and the appropriate method on the DAO is called to add a record.

The exception occurs on the instantiation of the DAO as it is in the constructor of the DAO where the EM gets created.

 All other scenarios don’t have the issue. For example, calling the DAO from an EJB or from the Servlet class or from a POJO class.

That is all working as expected. If the PU was loaded for the first time in (for example) the EJB then the ManagedScheduledExecutorService is ok.

It is only when the PU must be loaded for the first time from an EE Concurrency Utility (ManagedScheduledExecutorService or ManagedExecutorService).

[Yeray Borges Santana]

Hi Linda,

Are you specifying Galleon layers with the Bootable JAR plugin configuration?, if so, which Galleon layers are you using?

Well, it would be better if you paste your Bootable JAR plugin configuration here.

Regards

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/b46779c9-70bf-48e9-b5d1-56694c9ddc46n%40googlegroups.com.

[Linda Janse van Rensburg]

With regards to this issue, the following:

I had to explicitly add context-service=default for the application specific Managed Executor Service and application specific Managed Scheduled Executor Service

/subsystem=ee/managed-scheduled-executor-service=TestAppScheduler:add(jndi-name=java:jboss/ee/concurrency/scheduler/TestAppScheduler, core-threads=20, context-service=default)

This doesn’t make sense to me as the WildFly documentation states that context-service is an optional attribute.

Thorntail I know assumes defaults for you when not specifying attributes, thus we never defined the context-service.

[Linda Janse van Rensburg]

So what I meant to say is that by explicitly adding context-service=default, solved this issue. Which is still confusing to me as  context-service=default  should be the default if you do not explicitly specify it.  

[Yeray Borges Santana]

Hi Linda,

Thanks for describing how you fixed your issue, that helps for anyone facing the same problem.

Sadly, although Thorntail is a framework based on WildFly, and you can find differences in how they behave, after all, they are different projects.

On Fri, May 20, 2022 at 4:15 AM 'Linda Janse van Rensburg' via WildFly <wil...@googlegroups.com> wrote:

So what I meant to say is that by explicitly adding context-service=default, solved this issue. Which is still confusing to me as  context-service=default  should be the default if you do not explicitly specify it.  

Regarding your point, it is worth mentioning that the context-service attribute for /subsystem=ee/managed-scheduled-executor-service resource, in WildFly is an optional attribute without a default value, so, if you don't specify it, it will get no value.

You can check the descriptions of the model resource attributes by looking at the WildFly Model reference. For example, you can expand the attribute description by selecting the 'context-service' on the following link:

https://docs.wildfly.org/26.1/wildscribe/subsystem/ee/managed-scheduled-executor-service/index.html

It specifies it can be null, but it doesn't specify it has a default value. You will get a similar output by using the following CLI management operation:

[standalone@localhost:9990 /] /subsystem=ee/managed-scheduled-executor-service=default:read-resource-description

{
    "outcome" => "success",
    "result" => {
        "description" => "A managed scheduled executor service",
        "capabilities" => [{
            "name" => "org.wildfly.ee.concurrent.scheduled-executor",
            "dynamic" => true,
            "dynamic-elements" => ["managed-scheduled-executor-service"]
        }],
        "attributes" => {

......

       "context-service" => {
                "type" => STRING,
                "description" => "The name of the context service to be used by the scheduled executor.",
                "expressions-allowed" => false,
                "required" => false,
                "nillable" => true,
                "capability-reference" => "org.wildfly.ee.concurrent.context.service",
                "min-length" => 0L,
                "max-length" => 2147483647L,
                "access-type" => "read-write",
                "storage" => "configuration",
                "restart-required" => "resource-services"
            },

....

If you have found in our documentation that this attribute is optional and by default, it gets the value "context-service=default", then we have a bug in the documentation and we have to fix it, otherwise, the behavior getting it null if you don't specify it, is what it is expected.

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/b885b801-bd54-4167-9e69-4e3ea00dd7cbn%40googlegroups.com.

[Linda Janse van Rensburg]

Thank you!

WildFly documentation only states that it is optional, it was in the thorntail doc that it states it will assume default values.