[JBoss JIRA] (WFLY-4212) REGRESSION: CDI application fails to deploy in 8.2.0 vs 8.1.0
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4212?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov edited comment on WFLY-4212 at 1/7/15 8:00 PM:
--------------------------------------------------------------
We're using Jandex maven plugin version 1.0.1 while building all of our deployment units and their component JARs. There is no newer version.
Are you meaning to say that jandex maven plugin should never be used anymore?
was (Author: arcivanov):
We're using Jandex maven plugin version 1.0.1 while building all of our deployment units and their component JARs. There is no newer version.
> REGRESSION: CDI application fails to deploy in 8.2.0 vs 8.1.0
> -------------------------------------------------------------
>
> Key: WFLY-4212
> URL: https://issues.jboss.org/browse/WFLY-4212
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Reporter: Arcadiy Ivanov
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: 8.1.0-cluster_logs.2014-12-31T04-01-53.tar.gz, 8.2.0-cluster_logs.2014-12-31T04-19-06.tar.gz
>
>
> While testing an upgrade to 8.2.0 a multi-component integration test that worked on 8.1.0 failed to deploy.
> A distilled clean-room test case reproducing the problem is located here: https://github.com/arcivanov/misc/tree/WFCORE-488/WFCORE-488
> This bug is also accompanied by the failure to undeploy partial deployment in WFCORE-488, although at present the above test case not yet reproduces the behavior.
> The deployment error on 8.2.0 is as follows:
> {noformat}
> 2014-12-31 04:17:11,877 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."bf40aa60-1792-473b-bc2c-344adf89790c.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."bf40aa60-1792-473b-bc2c-344adf89790c.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:372)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:293)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:167)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:531)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_25]
> ... 3 more
> 2014-12-31 04:17:11,886 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 66) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "bf40aa60-1792-473b-bc2c-344adf89790c.ear")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> "}}
> 2014-12-31 04:17:11,889 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 66) JBAS015870: Deploy of deployment "bf40aa60-1792-473b-bc2c-344adf89790c.ear" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> "}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4212) REGRESSION: CDI application fails to deploy in 8.2.0 vs 8.1.0
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4212?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov commented on WFLY-4212:
--------------------------------------
We're using Jandex maven plugin version 1.0.1 while building all of our deployment units and their component JARs. There is no newer version.
> REGRESSION: CDI application fails to deploy in 8.2.0 vs 8.1.0
> -------------------------------------------------------------
>
> Key: WFLY-4212
> URL: https://issues.jboss.org/browse/WFLY-4212
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Reporter: Arcadiy Ivanov
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: 8.1.0-cluster_logs.2014-12-31T04-01-53.tar.gz, 8.2.0-cluster_logs.2014-12-31T04-19-06.tar.gz
>
>
> While testing an upgrade to 8.2.0 a multi-component integration test that worked on 8.1.0 failed to deploy.
> A distilled clean-room test case reproducing the problem is located here: https://github.com/arcivanov/misc/tree/WFCORE-488/WFCORE-488
> This bug is also accompanied by the failure to undeploy partial deployment in WFCORE-488, although at present the above test case not yet reproduces the behavior.
> The deployment error on 8.2.0 is as follows:
> {noformat}
> 2014-12-31 04:17:11,877 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."bf40aa60-1792-473b-bc2c-344adf89790c.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."bf40aa60-1792-473b-bc2c-344adf89790c.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:372)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:293)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:167)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:531)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_25]
> ... 3 more
> 2014-12-31 04:17:11,886 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 66) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "bf40aa60-1792-473b-bc2c-344adf89790c.ear")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> "}}
> 2014-12-31 04:17:11,889 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 66) JBAS015870: Deploy of deployment "bf40aa60-1792-473b-bc2c-344adf89790c.ear" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> "}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4212) REGRESSION: CDI application fails to deploy in 8.2.0 vs 8.1.0
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4212?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4212:
--------------------------------------
This is cause by the deployment generating a jandex annotation index using an old version of Jandex. If you don't generate the index at build time wildfly will generate it automatically. Unless the deployment is massive you are unlikely to see any noticeable change in deployment time generating it at build time rather than leaving this up to Wildfly.
> REGRESSION: CDI application fails to deploy in 8.2.0 vs 8.1.0
> -------------------------------------------------------------
>
> Key: WFLY-4212
> URL: https://issues.jboss.org/browse/WFLY-4212
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Reporter: Arcadiy Ivanov
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: 8.1.0-cluster_logs.2014-12-31T04-01-53.tar.gz, 8.2.0-cluster_logs.2014-12-31T04-19-06.tar.gz
>
>
> While testing an upgrade to 8.2.0 a multi-component integration test that worked on 8.1.0 failed to deploy.
> A distilled clean-room test case reproducing the problem is located here: https://github.com/arcivanov/misc/tree/WFCORE-488/WFCORE-488
> This bug is also accompanied by the failure to undeploy partial deployment in WFCORE-488, although at present the above test case not yet reproduces the behavior.
> The deployment error on 8.2.0 is as follows:
> {noformat}
> 2014-12-31 04:17:11,877 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."bf40aa60-1792-473b-bc2c-344adf89790c.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."bf40aa60-1792-473b-bc2c-344adf89790c.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_25]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_25]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:372)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:293)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:167)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:531)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_25]
> ... 3 more
> 2014-12-31 04:17:11,886 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 66) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "bf40aa60-1792-473b-bc2c-344adf89790c.ear")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> "}}
> 2014-12-31 04:17:11,889 ERROR [org.jboss.as.server] (ServerService Thread Pool -- 66) JBAS015870: Deploy of deployment "bf40aa60-1792-473b-bc2c-344adf89790c.ear" was rolled back with the following failure message:
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"bf40aa60-1792-473b-bc2c-344adf89790c.ear\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type DateGenerator with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private wfcore488.ejb.ExampleEjb.dateGen
> at wfcore488.ejb.ExampleEjb.dateGen(ExampleEjb.java:0)
> "}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4162) Intermittent failure in ExcludeEjbSubsystemTestCase
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4162?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4162:
--------------------------------------
This PR adds a little bit more info to the test https://github.com/wildfly/wildfly/pull/7081
> Intermittent failure in ExcludeEjbSubsystemTestCase
> ---------------------------------------------------
>
> Key: WFLY-4162
> URL: https://issues.jboss.org/browse/WFLY-4162
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Brian Stansberry
> Assignee: David Lloyd
>
> Three times in the past 6 weeks, ExcludeEjbSubsystemTestCase has failed due to the expected NamingException not being thrown. All three failures are on Windows.
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF_PullReque...
> Note the failure message is a bit confusing. It's the "Caused by" in the stack trace that shows the NamingException didn't happen:
> {code}
> java.lang.Exception: Unexpected exception, expected<javax.naming.NameNotFoundException> but was<java.lang.AssertionError>
> at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:28)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Caused by: java.lang.AssertionError: Expected exception: javax.naming.NameNotFoundException
> at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:32)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:129)
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:108)
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214)
> at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
> at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1530)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:748)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:952)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
> at org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3293) Excessive ERROR logging on JBAS014559: Invocation cannot proceed as component is shutting dow
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3293?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-3293.
----------------------------------
Resolution: Done
It is now possible to disable the EJB exception logging interceptor
> Excessive ERROR logging on JBAS014559: Invocation cannot proceed as component is shutting dow
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-3293
> URL: https://issues.jboss.org/browse/WFLY-3293
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Thomas Frühbeck
> Assignee: David Lloyd
> Priority: Minor
>
> on server shutdown excessive ERROR logs are produced related to EJB invocations on beans in state shutdown.
> 2014-04-26 09:38:43,059 ERROR [org.jboss.as.ejb3.invocation] (ServerService Thread Pool -- 377) JBAS014134: EJB Invocation failed on component SMSQueueConsumer for method public void at.telekom.sms.esms.service.
> common.queue.SMSQueueConsumer.stopping(): org.jboss.as.ejb3.component.EJBComponentUnavailableException: JBAS014559: Invocation cannot proceed as component is shutting down
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:59) [wildfly-ejb3-8.0.0.Final.jar:8.0.0.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> IMHO this is definitely no error and is very alarming for production environments, INFO w/o stacktrace, in level DEBUG full stacktrace would suffice.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3775) @TransactionAttribute ignored on non-public methods.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3775?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-3775:
------------------------------------
Assignee: Stuart Douglas (was: David Lloyd)
> @TransactionAttribute ignored on non-public methods.
> ----------------------------------------------------
>
> Key: WFLY-3775
> URL: https://issues.jboss.org/browse/WFLY-3775
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.1.0.Final
> Environment: SunOS, JDK1.7.
> Reporter: Sławomir Wojtasiak
> Assignee: Stuart Douglas
> Priority: Minor
>
> Currently @TransactionAttribute annotations are allowed only on public methods. It seems to be a reasonable rule because components are accesses by their public interfaces and session beans can be also accessed by a no-interface view that exposes all public methods of the bean class. Nevertheless in case of singletons @PostConstruct and @PreDestroy annotations can be applied to protected methods for instance. In such a case transaction attributes are silently ignored.
> (org.jboss.as.ejb3.component.EJBComponentCreateService:147)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-2967) Rationalize log-and-throw behavior in CMTTxInterceptor.handleInCallerTx
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2967?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2967:
--------------------------------------
I have removed this behaviour, we already have some rather unfortunate log and re-throw behaviour in the logging interceptor, which basically means that at the moment an exception may be logged twice for every EJB on the call stack (e.g. a servlet that called a chain of 3 EJB's could result in the exception being logged 7 times).
This should never have been there in the first place IMHO.
> Rationalize log-and-throw behavior in CMTTxInterceptor.handleInCallerTx
> -----------------------------------------------------------------------
>
> Key: WFLY-2967
> URL: https://issues.jboss.org/browse/WFLY-2967
> Project: WildFly
> Issue Type: Task
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Stuart Douglas
>
> CMTTxInterceptor.handleInCallerTx does a log-and-throw:
> {code}
> setRollbackOnly(tx);
> EjbLogger.ROOT_LOGGER.error(t);
> throw (Exception) t;
> {code}
> Generally this is an anti-pattern, although there may be utility in logging some events server-side as an aid in diagnostics or something. IMO if the exception indicates some sort of server fault, as opposed to a client or application state mistake, it needs to be logged server-side. But I'm not sure where the dividing line is.
> It doesn't look like this particular example is nicely playing such a role though.
> 1) It's only called in MANDATORY/REQUIRED/SUPPORTS scenarios where a tx already exists. So, what it logs is logged in some scenarios and not in others.
> 2) It logs stuff that looks pretty clearly like client mistakes, in particular NoSuchEJBException and NoSuchEntityException. I don't believe these add value to the server log, at least not at a level above DEBUG.
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3444) EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3444?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reopened WFLY-3444:
----------------------------------
Assignee: Stuart Douglas (was: David Lloyd)
> EjbTimerXmlPersister should check if timer.getNextExpiration() is null to avoid NPE
> -----------------------------------------------------------------------------------
>
> Key: WFLY-3444
> URL: https://issues.jboss.org/browse/WFLY-3444
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Scott Marlow
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> Seeing a NPE in org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister. that probably needs a null check:
> {quote}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeCalendarTimer(EjbTimerXmlPersister.java:136)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:89)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.EjbTimerXmlPersister.writeContent(EjbTimerXmlPersister.java:43)
> at org.jboss.staxmapper.XMLMapperImpl.doDeparse(XMLMapperImpl.java:88)
> at org.jboss.staxmapper.XMLMapperImpl.deparseDocument(XMLMapperImpl.java:83)
> at org.jboss.as.ejb3.timerservice.persistence.filestore.FileTimerPersistence.writeFile(FileTimerPersistence.java:440)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months