Persistence Units in persistence.xml files being scanned and validated from bundles included inside EAR project

[invinity]

Description

---

I have an existing project that has been deployed and running in Glassfish 4+ and Payara 4.1.1.163 for quite a while. Part of this project is a shared bundle that provides all JPA entities and a 'core' persistence.xml file. This shared bundle is also used in an OSGi component to the overall application, which is run from another JVM from Payara, so the bundle contains an OSGi-friendly persistence.xml and Meta-Persistence manifest declaration. We then have an EJB project which declares a JEE/Payara-friendly persistence.xml to compose a persistence-unit for our JEE environment that just references all the classes from the shared bundle. Then we build an EAR with our 'shared' bundle just stuffed into 'lib/' to be on the EAR's classpath.

In past releases of Payara this setup worked fine and Payara happily only honored the persistence.xml from our EJB project, while ignoring the persistence.xml inside the embedded jar. However, when trying to use/deploy this same application with 4.1.2.174 it fails with a message like this:

[2017-12-20T14:39:32.493-0600] [Payara 4.1] [SEVERE] [NCLS-CORE-00026] [javax.enterprise.system.core] [tid: _ThreadID=148 _ThreadName=AutoDeployer] [timeMillis: 1513802372493] [levelValue: 1000] [[ Exception during lifecycle processing org.glassfish.deployment.common.DeploymentException: JNDI lookup failed for the resource: Name: [my-shared-bundles-pu-name], Lookup: [osgi:service/javax.sql.DataSource/(&(osgi.jndi.service.name=my-osgi-ds)(!(aries.managed=true)))], Type: [javax.sql.DataSource]

So it would seem as though Payara is now somehow 'discovering' this persistence-unit defined in a bundle inside our EAR's lib directory and trying to validate the PU, which is failing b/c the datasource references in this PU are meant for the OSGi environment.

As a workaround I'm assuming I could move all my shared POJO entity classes into a non-persistence bundle and then include that in the EAR and OSGi builds accordingly. But there may be some classloading concerns in OSGi if my PU and my actual entities are in separate bundles. Another thought would be a fragment bundle approach which might alleviate potential classloading issues. Perhaps someone can confirm an approach like this as a workaround, and maybe even as a best-practice?

Expected Outcome

Payara should not discover PUs inside bundles embedded in an EAR's lib directory.

Current Outcome

Payara discovers persistence.xml files inside bundles embedded in EAR's lib directory and attempts to validate - and possibly provision - them.

Steps to reproduce (Only for bug reports)

1 -** Start the domain

./asadmin start-domain payaradomain

2 -** Build an EAR project with an embedded persistence-unit OSGi bundle with datasource declarations that don't match what is in Payara.

3 -** Attempt to deploy the EAR to payara and see it discover the PU in your embedded bundle and attempt to validate it and fail.

Samples

Context (Optional)

Environment

• Payara Version: 4.1.2.174
• Edition: Full
• JDK Version: 8
• Operating System: Windows and Linux
• Database: MySQL

[smillidge]

Can you create a simple test case we can use to reproduce the problem?

[invinity]

Sorry for the late response. I'll see if I can put together a test EAR.

If it's helpful, I can confirm that by splitting up my JPA entity classes from the osgi-friendly persistence.xml and Meta-Persistence 'bundle' and bundling the entity classes into the EAR without the OSGi PU stuff, that Payara happily loads and deploys the EAR including the EJB with working JPA PU.

I'm assuming at this point that the behavior change with Payara is either new, desired functionality, or unintentional. If you have any preliminary guidance on which of these you think it is it would help me a lot in moving forward with any changes I might need to make in order to run on the latest versions of Payara.

In the meantime I'll try to build that test case.

Thanks. -matt

[invinity]

OK, I have been able to replicate this behavior with a simple EAR project built from eclipse. It has an EJB project with a PU definition that I defined in Payara as just a basic Derby-embedded pool (I'll try to get a working asadmin command posted for this.

The entity classes themselves are contained in a PDE/OSGi project which has its own, separate PU definition that references datasources not defined in Payara. The EAR project bundles this osgi bundle inside its lib directory and upon attempting to deploy this project it fails with the following message.

cannot Deploy payara-jpa-with-embedded-pu-bundle deploy is failing=Error occurred during deployment: Exception while deploying the app [payara-jpa-with-embedded-pu-bundle] : JNDI lookup failed for the resource: Name: [payara-jpa-entities], Lookup: [this-data-source-isnt-in-payara-but-would-be-in-osgi], Type: [javax.sql.DataSource]. Please see server.log for more details.

Essentially, the PU deployment system in Payara is reading the Meta-Persistence header and persistence.xml file from within a jar inside the ear. This behavior is new to Payara, coming in sometime between 163 and 174.

payara-jpa-with-embedded-pu-bundle.ear.zip

[invinity]

Here's commands to create the needed JDBC pools and referring JNDI resource for the EJB datasource definition required by the sample EAR. Again, the sample EAR's EJB project has a PU that should load as expected and these commands create the required datasource. But, the overall deployment of the EAR still fails b/c Payara is now scanning and finding a PU inside an embedded JAR within the EAR.

asadmin create-jdbc-connection-pool --datasourceclassname org.apache.derby.jdbc.EmbeddedDataSource40 --restype javax.sql.DataSource --property DatabaseName=payara-jpa-testing:ConnectionAttribute=";create\=true" payara-jpa-testing1

asadmin create-jdbc-resource --connectionpoolid payara-jpa-testing jdbc/payara-jpa-testing

[invinity]

Any word on this? Our team is trying to establish our strategy for maintaining upgradeability to the latest Payara releases since our current application build will not run on them.

[fturizo]

Due to the lack of a proper reproducer and the that the issue was tested on an older release of Payara Server, we'll close this issue. Feel free to raise a new issue if the problem is present in the current release of Payara Server and you can provide an appropriate reproducer.