[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Martin Herschke edited comment on WFLY-10253 at 5/2/18 1:35 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 give you the exact output. 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 several 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}} that might 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 {{META-INF\persistence.xml}} file {color:#707070}(in the stated folder){color}. The first one defines several 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}} that might add elements to the list of providers.
> ConcurrentModificationException on startup
> ------------------------------------------
>
> Key: WFLY-10253
> URL: https://issues.jboss.org/browse/WFLY-10253
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Reporter: Martin Herschke
> Assignee: Dmitrii Tikhomirov
>
> standalone wildfly startup: This exception appears sporadically and is caused by different modules and projects.
> Multiple threads are used to deploy modules ({{MSC service thread 1-7}}), but a static method {{lookupProvider}} is called. The provider list is a normal ArrayList that causes the exception.
> {code}
> 16:36:23,604 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of subdeployment "<our_module>" of deployment "<our_ear>"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:940)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.nextPhaseDependsOnPersistenceUnit(PersistenceUnitServiceHandler.java:1052)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:136)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Martin Herschke edited comment on WFLY-10253 at 5/2/18 1:32 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 several 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}} that might 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 {{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.
> ConcurrentModificationException on startup
> ------------------------------------------
>
> Key: WFLY-10253
> URL: https://issues.jboss.org/browse/WFLY-10253
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Reporter: Martin Herschke
> Assignee: Dmitrii Tikhomirov
>
> standalone wildfly startup: This exception appears sporadically and is caused by different modules and projects.
> Multiple threads are used to deploy modules ({{MSC service thread 1-7}}), but a static method {{lookupProvider}} is called. The provider list is a normal ArrayList that causes the exception.
> {code}
> 16:36:23,604 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of subdeployment "<our_module>" of deployment "<our_ear>"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:940)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.nextPhaseDependsOnPersistenceUnit(PersistenceUnitServiceHandler.java:1052)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:136)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ 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.
> ConcurrentModificationException on startup
> ------------------------------------------
>
> Key: WFLY-10253
> URL: https://issues.jboss.org/browse/WFLY-10253
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Reporter: Martin Herschke
> Assignee: Dmitrii Tikhomirov
>
> standalone wildfly startup: This exception appears sporadically and is caused by different modules and projects.
> Multiple threads are used to deploy modules ({{MSC service thread 1-7}}), but a static method {{lookupProvider}} is called. The provider list is a normal ArrayList that causes the exception.
> {code}
> 16:36:23,604 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of subdeployment "<our_module>" of deployment "<our_ear>"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:940)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.nextPhaseDependsOnPersistenceUnit(PersistenceUnitServiceHandler.java:1052)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:136)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10253) ConcurrentModificationException on startup
by Martin Herschke (JIRA)
[ https://issues.jboss.org/browse/WFLY-10253?page=com.atlassian.jira.plugin... ]
Martin Herschke commented on WFLY-10253:
----------------------------------------
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.
> ConcurrentModificationException on startup
> ------------------------------------------
>
> Key: WFLY-10253
> URL: https://issues.jboss.org/browse/WFLY-10253
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Reporter: Martin Herschke
> Assignee: Dmitrii Tikhomirov
>
> standalone wildfly startup: This exception appears sporadically and is caused by different modules and projects.
> Multiple threads are used to deploy modules ({{MSC service thread 1-7}}), but a static method {{lookupProvider}} is called. The provider list is a normal ArrayList that causes the exception.
> {code}
> 16:36:23,604 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."<our_ear>"."<our_module>".FIRST_MODULE_USE: WFLYSRV0153: Failed to process phase FIRST_MODULE_USE of subdeployment "<our_module>" of deployment "<our_ear>"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.lookupProvider(PersistenceUnitServiceHandler.java:940)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.nextPhaseDependsOnPersistenceUnit(PersistenceUnitServiceHandler.java:1052)
> at org.jboss.as.jpa.processor.PersistenceUnitServiceHandler.deploy(PersistenceUnitServiceHandler.java:136)
> at org.jboss.as.jpa.processor.PersistenceBeginInstallProcessor.deploy(PersistenceBeginInstallProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFCORE-3792) org.jboss.remoting module should be private
by Brad Maxwell (JIRA)
Brad Maxwell created WFCORE-3792:
------------------------------------
Summary: org.jboss.remoting module should be private
Key: WFCORE-3792
URL: https://issues.jboss.org/browse/WFCORE-3792
Project: WildFly Core
Issue Type: Bug
Components: Remoting
Affects Versions: 5.0.0.Alpha4
Reporter: Brad Maxwell
Assignee: David Lloyd
org.jboss.remoting module should be private
/core-feature-pack/src/main/resources/modules/system/layers/base/org/jboss/remoting/main/module.xml
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-9853) NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-9853?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-9853:
-----------------------------------------------
Jiří Bílek <jbilek(a)redhat.com> changed the Status of [bug 1510010|https://bugzilla.redhat.com/show_bug.cgi?id=1510010] from ON_QA to VERIFIED
> NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration
> -------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9853
> URL: https://issues.jboss.org/browse/WFLY-9853
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Chao Wang
> Assignee: Stefan Guilhen
>
> "NameNotFoundException due to policyRegistration -- service jboss.naming.context.java.policyRegistration" is recorded in server.log during quickstart example run by changing log level:
> {noformat}
> <logger category="org.jboss.as.security">
> <level name="TRACE"/>
> </logger>
> <logger category="org.jboss.security">
> <level name="TRACE"/>
> </logger>
> {noformat}
> See detailed description in community discussion [#907134|https://developer.jboss.org/message/907134]
> I choose Jira component picketbox since the exception is titled as "PBOX000293: Exception caught: javax.naming.NameNotFoundException"
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFCORE-3791) Cannot debug the subsystem transformer tests in IntelliJ
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-3791:
----------------------------------
Summary: Cannot debug the subsystem transformer tests in IntelliJ
Key: WFCORE-3791
URL: https://issues.jboss.org/browse/WFCORE-3791
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 5.0.0.Alpha4
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 5.0.0.Alpha5
If running tests from /home/wildfly/undertow the File determined by TransformationUtils.getDmrFile() is returned as /home/wildfly/test-classes rather than /home/wildfly/undertow/test-classes so the assertion fails
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months