[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ] Martin Herschke edited comment on WFLY-10253 at 5/2/18 1:24 PM: ---------------------------------------------------------------- Hi [~smarlow] {quote}Could you show us the contents of the EAR that you are deploying (output of "jar tf yourapp.ear" and also the contents of contained archives)? Mostly I am curious if there are any persistence provider jars contained in the EAR and if yes, the location in the EAR. I'm also interested in the location of the persistence.xml files in the EAR as well.{quote} I'm afraid I can't. It would give away customer-related informations. But if it's really necessary, I can request a shortened // anonymised version. What I can tell you though is that we have a fat ear consisting of 1x web archive, ~20x jar modules {color:#707070}(two of them containing a persistence.xml){color}, some rar modules and a lib folder including several other jars {color:#707070}(mostly emf, etc.){color}. *customer-ear* * _customer.war_ * base-commons.jar * base-i18n.jar * base-model.jar * base-domain.jar * base-business.jar * base-communications.jar * customer-commons.jar * customer-i18n.jar * customer-model.jar * customer-domain.jar => containing persistence.xml * customer-business.jar * customer-communications.jar * ... _some other jars / rars_ * user-preferences.jar => additional persistence.xml * lib/ ... _all the other dependencies_ Both jars contain a single {{META-INF\persistence.xml}} file {color:#707070}(in the stated folder){color}. The first one defines multiple datasources responsible for our normal workflow. The second one defines a single, separate datasource that helps us store 'user-preferences' like filter settings, etc. Both reside directly inside the ear {color:#707070}(as shown above){color}. And in response to this statement: {quote}I think this is probably a symptom of a different problem, deployers should not be iterating over lists that are in the process of being concurrently changed, as that may give inconsistent deployment results.{quote} The iteration over the persistence providers is done by the {{PersistenceUnitServiceHandler#lookupProvider}} itself... and the very same method also seems to call {{PersistenceProviderDeploymentHolder#savePersistenceProviderInDeploymentUnit}} to add elements to the list of providers. was (Author: mhk): Hi [~smarlow] {quote}Could you show us the contents of the EAR that you are deploying (output of "jar tf yourapp.ear" and also the contents of contained archives)? Mostly I am curious if there are any persistence provider jars contained in the EAR and if yes, the location in the EAR. I'm also interested in the location of the persistence.xml files in the EAR as well.{quote} I'm afraid I can't. It would give away customer-related informations. But if it's really necessary, I can request a shortened // anonymised version. What I can tell you though is that we have a fat ear consisting of 1x web archive, ~20x jar modules {color:#707070}(two of them containing a persistence.xml){color}, some rar modules and a lib folder including several other jars {color:#707070}(mostly emf, etc.){color}. *customer-ear* * _customer.war_ * base-commons.jar * base-i18n.jar * base-model.jar * base-domain.jar * base-business.jar * base-communications.jar * customer-commons.jar * customer-i18n.jar * customer-model.jar * customer-domain.jar => containing persistence.xml * customer-business.jar * customer-communications.jar * ... _some other jars / rars_ * user-preferences.jar => additional persistence.xml * lib/ ... _all the other dependencies_ Both jars contain a single {{src\main\resources\META-INF\persistence.xml}} file {color:#707070}(in the stated folder){color}. The first one defines multiple datasources responsible for our normal workflow. The second one defines a single, separate datasource that helps us store 'user-preferences' like filter settings, etc. Both reside directly inside the ear {color:#707070}(as shown above){color}. And in response to this statement: {quote}I think this is probably a symptom of a different problem, deployers should not be iterating over lists that are in the process of being concurrently changed, as that may give inconsistent deployment results.{quote} The iteration over the persistence providers is done by the {{PersistenceUnitServiceHandler#lookupProvider}} itself... and the very same method also seems to call {{PersistenceProviderDeploymentHolder#savePersistenceProviderInDeploymentUnit}} to add elements to the list of providers. -- This message was sent by Atlassian JIRA (v7.5.0#75005)