Persistence unit not found in wildfly module

Question

My scenario is as follows: I have a bunch of different applications (WARs) running on a WildFly server. One common functionality of each of them is, that they should look up something in a database and behave different, if a specific flag is set (kind of an advanced "kill switch" with some finer-grained configurability).

The whole thing is realized as a filter, called on every request (with some caching to avoid querying the database too often). This is intended and works like it should, if I integrate the filter logic (let's call it killswitch.jar ) in every single war application (and configure the web.xml accordingly).

From a perspective of maintainability and redundancy avoidance, I find this a little dissatisfactory. Therefore I'd like to put the whole thing into a WildFly module in order to avoid bundling the jar in every war. I put the jar and the module.xml (as follows) in the right place and the module gets loaded.

module.xml :

<?xml version="1.0" encoding="UTF-8"?> 
<module xmlns="urn:jboss:module:1.0" name="my.company.domain.killswitch">
     <resources>    
          <resource-root path="killswitch.jar"/>
     </resources>  
     <dependencies>    
          <module name="org.jboss.logging"/>
          <module name="javax.api"/>
          <module name="com.microsoft.sqlserver"/>
          <module name="org.slf4j.jcl-over-slf4j"/>
          <module name="org.jboss.as.web" />
          <module name="javax.servlet.api" />
          <module name="javax.persistence.api" />
          <module name="javax.api"/>
          <module name="javax.inject.api"/>
          <module name="org.hibernate" services="import"/>
      </dependencies>
</module> 

(In fact, this is not the whole truth: This module is loaded in hierarchy of modules. Module A depends on module B and module B depends on this one. But as I see it, this works and all three of them get loaded, so IMHO this shouldn't matter.)

The problem is, that the persistence unit defined in the module is not found on server startup:

Can't find a persistence unit named 'Killswitch' in deployment MyAwesomeApplication.war

But, as you can imagine, the persistence unit is there. The persistence.xml also, of course, and it is well-formed and valid. I can definitely confirm this, as it works without any changes, if used not as a module.

I've read a couple of threads about similar issues. Some state, it isn't possible to achieve, what I try to. Others talk about META-INF , ClassLoaders or the order of the modules being loaded. I tried some of the solutions, but with no success. As I'm not a wildfly or JAP professional, I'm at a loss now and asking for your kind help:

1. Is it possible to achieve my goal at all?
2. If so, how would you do it? If not, can you think of any other alternative to bundling the killswitch.jar in every war?

Many thanks in advance!

Answer 1

Although my scenario is different from your, i had the same issue with Wildfly not finding the persistence unit, even it was there.

After hours of struggling and searching, i've solved my issue simply putting my persistence.xml in the META-INF folder of one of the JARs that my WAR depends on.

You can also build a single lightweight jar that contains solely the META-INF with the persistence.xml file, or even better add it in one of the JARs that your WAR depends on.

The official documentation of Wildfly states this:

The persistence.xml contains the persistence unit configuration (eg datasource name) and as described in the JPA 2.0 spec (section 8.2), the jar file or directory whose META-INF directory contains the persistence.xml file is termed the root of the persistence unit. In Java EE environments, the root of a persistence unit must be one of the following (quoted directly from the JPA 2.0 specification):

"

• an EJB-JAR file
• the WEB-INF/classes directory of a WAR file
• a jar file in the WEB-INF/lib directory of a WAR file
• a jar file in the EAR library directory
• an application client jar file

"

Note that, in many answers that i've found, the second option seems to be not working.

Hope it can help you and others with the same issue