Thanks for the asnwer.
Following your link i entered the standalone.xml file and i have activated the trace log leve.
During the wildfly startup i see trace log lines like :
TRACE [org.jboss.as.jpa] (MSC service thread 1-1) parse checking if
"/D:/CodeHome/keycloak-demo-1.4.0.Final/keycloak/bin/content/MyFistModule.jar/META-INF/persistence.xml" exists, result = false
TRACE [org.jboss.as.jpa] (MSC service thread 1-1) parsed persistence unit definitions for jar MyFirstModule.jar
MyFirstModule is a keycloak provider and is deployedby the web admin console deployments procedure.
But i don't see any reference to MySecondModule which is the one implementing the JPA and DAO logic.
I have deployed it simply by creating : <Wildfly-server>/modules/com/myapplication/MySecondModule/main/MySecondModule.jar
and creating the module.xml
<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.myapplication.MySecondModule">
<resource-root path="MySecondModule.jar .jar"/>
<module name="org.apache.commons.logging" />
Do i miss anything?
MySecondModule is not going to be deployed like an application would be. Application deployments are scanned for persistence.xml files but <wildfly>modules are not. So the persistence context will always be null, unless you handle initializing it yourself.
For example, you could initialize it via javax.persistence.Persistence.createEntityManagerFactory(String puName, Map properties), however, the (persistence unit specificed) providerName class has to be available when starting the application server. Keep the org.jboss.as.jpa TRACE logging enabled, while you set this up. I think the TRACE log output will help. Depending on which persistence provider implementation you are using, you might also enable TRACE logging for that (e.g. org.hibernate).
With a change to use the Persistence bootstrap, you are going to manage the EntityManagerFactory directly. Depending on which persistence provider you are using, you may also need to pass certain integration property settings on the call to createEntityManagerFactory. Keep in mind that EntityManagerFactories are thread safe but EntityManager's are not.
really thanks for the answer. Indeed using a Java SE approach is what i did till now, even if i was not surrending to the idea of not having container handled transactions.
So i will proceed with Persistence.createEntityManagerFactory method.
Did you manage to resolve this issue as I have a similar problem with a module