[JBoss JIRA] (WFCORE-2631) UnsupportedOperationException for {allow-resource-service-restart=true} for inner attributes in Elytron subsystem
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFCORE-2631:
------------------------------------
Summary: UnsupportedOperationException for {allow-resource-service-restart=true} for inner attributes in Elytron subsystem
Key: WFCORE-2631
URL: https://issues.jboss.org/browse/WFCORE-2631
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Security
Reporter: Ondrej Lukas
Assignee: Brian Stansberry
Priority: Critical
In case when resource in Elytron subsystem includes {{attributes}} which have set {{"restart-required" => "resource-services"}} and includes also some {{"value-type"}} for inner attributes, then flag {{allow-resource-service-restart=true}} cannot be used correctly for those inner attributes.
See example:
{code}
/subsystem=elytron/properties-realm=ManagementRealm:write-attribute(name=users-properties.plain-text,value=true)
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{code}
This command set server to {{"reload-required"}} state. However In case, when flag {{allow-resource-service-restart=true}} is set, then UnsupportedOperationException is returned for the same command.
{code}
/subsystem=elytron/properties-realm=ManagementRealm:write-attribute(name=users-properties.plain-text,value=true){allow-resource-service-restart=true}
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.UnsupportedOperationException",
"rolled-back" => true
}
{code}
In case when operation set server to {{"process-state" => "reload-required"}} then flag {{allow-resource-service-restart=true}} should be supported. Otherwise whole server needs to be reloaded.
Exception thrown to server log for mentioned above CLI command:
{code}
ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("write-attribute") failed - address: ([
("subsystem" => "elytron"),
("properties-realm" => "ManagementRealm")
]): java.lang.UnsupportedOperationException
at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:145)
at org.jboss.as.controller.RestartParentWriteAttributeHandler.recreateParentService(RestartParentWriteAttributeHandler.java:126)
at org.jboss.as.controller.RestartParentWriteAttributeHandler.applyUpdateToRuntime(RestartParentWriteAttributeHandler.java:72)
at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:104)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:979)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:722)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:441)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1397)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:421)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2630) InterfaceManagementUnitTestCase from wf-core fail intermittently
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2630?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved JBEAP-10164 to WFCORE-2630:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2630 (was: JBEAP-10164)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Test Suite
(was: Domain Management)
(was: Test Suite)
Affects Version/s: (was: 7.1.0.DR10)
> InterfaceManagementUnitTestCase from wf-core fail intermittently
> ----------------------------------------------------------------
>
> Key: WFCORE-2630
> URL: https://issues.jboss.org/browse/WFCORE-2630
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
> Priority: Minor
>
> *Description of problem:*
> InterfaceManagementUnitTestCase from wf-core fail intermittently. This test is unit test from server module.
> *How reproducible:*
> 5%
> *Actual results:*
> StackTrace:
> {noformat}
> java.lang.AssertionError: {"outcome" => "success"}
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.jboss.as.server.test.InterfaceManagementUnitTestCase.executeForServiceFailure(InterfaceManagementUnitTestCase.java:447)
> at org.jboss.as.server.test.InterfaceManagementUnitTestCase.testInterfacesAlternatives(InterfaceManagementUnitTestCase.java:175)
> {noformat}
> Standard Output
> {noformat}
> Failure for {
> "operation" => "add",
> "address" => [("interface" => "test")],
> "any-address" => true,
> "inet-address" => "127.0.0.1",
> "link-local-address" => true,
> "loopback" => true,
> "loopback-address" => "127.0.0.1",
> "multicast" => true,
> "nic" => "lo",
> "nic-match" => "lo",
> "point-to-point" => true,
> "public-address" => true,
> "site-local-address" => true,
> "subnet-match" => "127.0.0.0/24",
> "up" => true,
> "virtual" => true
> }
> is:
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0099: any-address is invalid",
> "rolled-back" => true
> }
> Failure for {
> "operation" => "add",
> "address" => [("interface" => "test")],
> "inet-address" => "127.0.0.1",
> "link-local-address" => true,
> "loopback" => true,
> "loopback-address" => "127.0.0.1",
> "multicast" => true,
> "nic" => "lo",
> "nic-match" => "lo",
> "point-to-point" => true,
> "public-address" => true,
> "site-local-address" => true,
> "subnet-match" => "127.0.0.0/24",
> "up" => true,
> "virtual" => true
> }
> is:
> {"outcome" => "success"}
> {noformat}
> *Expected results:*
> No error
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (DROOLS-1514) Data Object source modify retains validation error
by Roger Martínez (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1514?page=com.atlassian.jira.plugi... ]
Roger Martínez reassigned DROOLS-1514:
--------------------------------------
Assignee: Walter Medvedeo (was: Roger Martínez)
> Data Object source modify retains validation error
> --------------------------------------------------
>
> Key: DROOLS-1514
> URL: https://issues.jboss.org/browse/DROOLS-1514
> Project: Drools
> Issue Type: Bug
> Components: docker images
> Affects Versions: 6.5.0.Final
> Environment: workbench-showcase docker image
> Reporter: Steven Waldren
> Assignee: Walter Medvedeo
>
> 1. Created new Data Object using editor
> 2. In source view of data object, added method ("addCode") to add item to field that is a List
> 3. Error though during validation.
> 4. Removed added method and saved.
> 5. Validation error remained "Rule Compilation error addCode cannot be resolved or is not a field"
> 6. Deleted data object
> 7. Added fields in editor
> 8. Validation error remained for "addCode" where there is no "addCode" in the entire repository anymore.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (DROOLS-1514) Data Object source modify retains validation error
by Steven Waldren (JIRA)
Steven Waldren created DROOLS-1514:
--------------------------------------
Summary: Data Object source modify retains validation error
Key: DROOLS-1514
URL: https://issues.jboss.org/browse/DROOLS-1514
Project: Drools
Issue Type: Bug
Components: docker images
Affects Versions: 6.5.0.Final
Environment: workbench-showcase docker image
Reporter: Steven Waldren
Assignee: Roger Martínez
1. Created new Data Object using editor
2. In source view of data object, added method ("addCode") to add item to field that is a List
3. Error though during validation.
4. Removed added method and saved.
5. Validation error remained "Rule Compilation error addCode cannot be resolved or is not a field"
6. Deleted data object
7. Added fields in editor
8. Validation error remained for "addCode" where there is no "addCode" in the entire repository anymore.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-8518) Deployments fails if AsyncListener in WEB-INF/classes or in a jar in WEB-INF/lib implements a class that isn't on the classpath
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-8518:
------------------------------------
Summary: Deployments fails if AsyncListener in WEB-INF/classes or in a jar in WEB-INF/lib implements a class that isn't on the classpath
Key: WFLY-8518
URL: https://issues.jboss.org/browse/WFLY-8518
Project: WildFly
Issue Type: Bug
Components: EE
Affects Versions: 9.0.2.Final, 10.1.0.Final
Reporter: Andy Wilkinson
Assignee: Stuart Douglas
If a web application contains, anywhere in {{WEB-INF/classes}} or a jar in {{WEB-INF/lib}}, an {{AsyncListener}} that implements an interface that isn't on the classpath, deployment of the web application will fail. A concrete example is Spring Framework's {{spring-web}} module which contains [such a listener|https://github.com/spring-projects/spring-framework/blob/f716c8e...].
When a war file is deployed to Wildfly 9.0.2.Final with {{spring-web}} in {{WEB-INF/lib}} deployment fails:
{noformat}
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."bootapp.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."bootapp.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "bootapp.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
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.lang.LinkageError: Failed to link org/springframework/http/server/reactive/ServletHttpHandlerAdapter$HandlerResultSubscriber (Module "deployment.bootapp.war:main" from Service Module Loader)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:269)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77)
at org.jboss.modules.Module.loadModuleClass(Module.java:560)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.server.deployment.reflect.DeploymentClassIndex.classIndex(DeploymentClassIndex.java:54)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:85)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:77)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
... 5 more
Caused by: java.lang.NoClassDefFoundError: org/reactivestreams/Subscriber
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:353)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:432)
... 19 more
Caused by: java.lang.ClassNotFoundException: org.reactivestreams.Subscriber from [Module "deployment.bootapp.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
... 23 more
{noformat}
This listener is only ever actually registered when the {{Subscriber}} class is on the classpath so it seems unreasonable for it to cause a failure at deployment time.
I'll attach a very basic example that triggers a similar problem. In the case of the example it fails with the following upon deployment to Wildfly 10.1.0.Final:
{noformat}
15:52:51,752 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."wildfly-problem.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-problem.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "wildfly-problem.war"
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.lang.NoClassDefFoundError: Failed to link com/example/BrokenAsyncListener (Module "deployment.wildfly-problem.war:main" from Service Module Loader): org/reactivestreams/Subscriber
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
at org.jboss.modules.Module.loadModuleClass(Module.java:606)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.as.ee.utils.ClassLoadingUtils.loadClass(ClassLoadingUtils.java:21)
at org.jboss.as.ee.utils.ClassLoadingUtils.loadClass(ClassLoadingUtils.java:14)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:84)
at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:76)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-8515) Deployments fails if AsyncListener in WEB-INF/classes or in a jar in WEB-INF/lib implements a class that isn't on the classpath
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-8515?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-8515:
------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> Deployments fails if AsyncListener in WEB-INF/classes or in a jar in WEB-INF/lib implements a class that isn't on the classpath
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8515
> URL: https://issues.jboss.org/browse/WFLY-8515
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.2.Final, 10.1.0.Final
> Reporter: Andy Wilkinson
> Assignee: Stuart Douglas
> Attachments: wildfly-problem.zip
>
>
> If a web application contains, anywhere in {{WEB-INF/classes}} or a jar in {{WEB-INF/lib}}, an {{AsyncListener}} that implements an interface that isn't on the classpath, deployment of the web application will fail. A concrete example is Spring Framework's {{spring-web}} module which contains [such a listener|https://github.com/spring-projects/spring-framework/blob/f716c8e...].
> When a war file is deployed to Wildfly 9.0.2.Final with {{spring-web}} in {{WEB-INF/lib}} deployment fails:
> {noformat}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."bootapp.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."bootapp.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "bootapp.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> 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.lang.LinkageError: Failed to link org/springframework/http/server/reactive/ServletHttpHandlerAdapter$HandlerResultSubscriber (Module "deployment.bootapp.war:main" from Service Module Loader)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:437)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:269)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:77)
> at org.jboss.modules.Module.loadModuleClass(Module.java:560)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.server.deployment.reflect.DeploymentClassIndex.classIndex(DeploymentClassIndex.java:54)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:85)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:77)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> Caused by: java.lang.NoClassDefFoundError: org/reactivestreams/Subscriber
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:353)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:432)
> ... 19 more
> Caused by: java.lang.ClassNotFoundException: org.reactivestreams.Subscriber from [Module "deployment.bootapp.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
> ... 23 more
> {noformat}
> This listener is only ever actually registered when the {{Subscriber}} class is on the classpath so it seems unreasonable for it to cause a failure at deployment time.
> I'll attach a very basic example that triggers a similar problem. In the case of the example it fails with the following upon deployment to Wildfly 10.1.0.Final:
> {noformat}
> 15:52:51,752 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.deployment.unit."wildfly-problem.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-problem.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "wildfly-problem.war"
> 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.lang.NoClassDefFoundError: Failed to link com/example/BrokenAsyncListener (Module "deployment.wildfly-problem.war:main" from Service Module Loader): org/reactivestreams/Subscriber
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:606)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.as.ee.utils.ClassLoadingUtils.loadClass(ClassLoadingUtils.java:21)
> at org.jboss.as.ee.utils.ClassLoadingUtils.loadClass(ClassLoadingUtils.java:14)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:84)
> at org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:76)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-477) RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-477?page=com.atlassian.jira.plugin... ]
James Perkins closed WFCORE-477.
--------------------------------
Resolution: Out of Date
No longer seems to be an issue.
> RootSubsystemOperationsTestCase fails if log directory wasn't properly cleaned
> ------------------------------------------------------------------------------
>
> Key: WFCORE-477
> URL: https://issues.jboss.org/browse/WFCORE-477
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Some test appears to not be cleaning up the {{target/logs}} directory which causes the tests to fail. While tests should be cleaning up after themselves, the test in the {{RootSubsystemOperationsTestCase}} should also not look for empty directories, but look for the files that _shouldn't_ be there.
> Files left behind:
> {code}
> [root@build01 logging]# ls -l target/logs/
> total 0
> -rw-r--r-- 1 root root 0 Oct 28 23:00 another.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 anotherProfile.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 fileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 profileFileHandler.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 server.log
> -rw-r--r-- 1 root root 0 Oct 28 23:00 sizeLogger.log
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-8517) ActiveMQ JGroups-based discovery is broken
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-8517?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-8517.
------------------------------
Resolution: Out of Date
> ActiveMQ JGroups-based discovery is broken
> ------------------------------------------
>
> Key: WFLY-8517
> URL: https://issues.jboss.org/browse/WFLY-8517
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 11.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> JGroups-based discovery was broken by this commit:
> https://github.com/wildfly/wildfly/commit/b0244166a3a72aa891aa37ec7b0b866...
> {noformat}
> 2017-04-04 13:56:47,301 WARN [org.apache.activemq.artemis.core.client] (Thread-1 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@66462207-730663955)) AMQ212025: did not conne
> ct the cluster connection to other nodes: ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=AMQ119013: Timed out waiting to receive cluster topology. Group:org.apache.activemq.artemis.co
> re.cluster.DiscoveryGroup@391e867]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:803)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:627)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.connect(ServerLocatorImpl.java:609)
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl$5.run(ServerLocatorImpl.java:1533)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2182) RuntimeVaultReader should not throw SecurityException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2182?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-2182:
-------------------------------------------------
Radovan Netuka <rnetuka(a)redhat.com> changed the Status of [bug 1410583|https://bugzilla.redhat.com/show_bug.cgi?id=1410583] from POST to MODIFIED
> RuntimeVaultReader should not throw SecurityException
> -----------------------------------------------------
>
> Key: WFCORE-2182
> URL: https://issues.jboss.org/browse/WFCORE-2182
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha20
>
>
> RuntimeVaultReader is throwing SecurityException if it catches a SecurityVaultException from PicketBoxSecurityVault. But the causes of those SecurityVaultException are not really security breaches, they just reflect failed searches, or, less likely, incorrect vault setup.
> Converting these into SecurityException, which is a RuntimeException, means the vault lookup will fail the management op that triggered it in a way that overrides rollback-on-runtime-failure=false. But at least in the case of failed searches, this is no different than any other failed attempt to resolve an expression and should be treated as such.
> Perhaps the type of the getCause() value from the SecurityVaultException can be used to discriminate behavior between failed searches and other issues, or perhaps the distinction can be ignored.
> Here is an example of a failed search using EAP 6:
> {code}
> 12:46:34,830 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 27) JBAS014612: Operation ("enable") failed - address: ([
> ("subsystem" => "datasources"),
> ("data-source" => "xyzDS")
> ]): java.lang.SecurityException: JBAS013311: Security Exception
> at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:115)
> at org.jboss.as.server.RuntimeExpressionResolver.resolvePluggableExpression(RuntimeExpressionResolver.java:45)
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionString(ExpressionResolverImpl.java:319) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.parseAndResolve(ExpressionResolverImpl.java:228) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionStringRecursively(ExpressionResolverImpl.java:130) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressionsRecursively(ExpressionResolverImpl.java:72) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ExpressionResolverImpl.resolveExpressions(ExpressionResolverImpl.java:54) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ModelControllerImpl.resolveExpressions(ModelControllerImpl.java:782) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.OperationContextImpl.resolveExpressions(OperationContextImpl.java:1002) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ParallelBootOperationContext.resolveExpressions(ParallelBootOperationContext.java:351) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AttributeDefinition$1.resolveExpressions(AttributeDefinition.java:338) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AttributeDefinition.resolveValue(AttributeDefinition.java:402) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AttributeDefinition.resolveModelAttribute(AttributeDefinition.java:361) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AttributeDefinition.resolveModelAttribute(AttributeDefinition.java:335) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.connector.util.ModelNodeUtil.getResolvedStringIfSetOrGetDefault(ModelNodeUtil.java:33)
> at org.jboss.as.connector.subsystems.datasources.DataSourceModelNodeUtil.from(DataSourceModelNodeUtil.java:151)
> at org.jboss.as.connector.subsystems.datasources.DataSourceEnable.addServices(DataSourceEnable.java:183)
> at org.jboss.as.connector.subsystems.datasources.DataSourceEnable$1.execute(DataSourceEnable.java:102)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:708) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:543) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:355) [jboss-as-controller-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_111]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_111]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> Caused by: org.jboss.security.vault.SecurityVaultException: java.lang.IllegalArgumentException: Null input buffer
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.retrieve(PicketBoxSecurityVault.java:297)
> at org.jboss.as.security.vault.RuntimeVaultReader.getValue(RuntimeVaultReader.java:141)
> at org.jboss.as.security.vault.RuntimeVaultReader.getValueAsString(RuntimeVaultReader.java:123)
> at org.jboss.as.security.vault.RuntimeVaultReader.retrieveFromVault(RuntimeVaultReader.java:113)
> ... 26 more
> Caused by: java.lang.IllegalArgumentException: Null input buffer
> at javax.crypto.Cipher.doFinal(Cipher.java:2161) [jce.jar:1.8.0_111]
> at org.picketbox.util.EncryptionUtil.decrypt(EncryptionUtil.java:134)
> at org.picketbox.plugins.vault.PicketBoxSecurityVault.retrieve(PicketBoxSecurityVault.java:293)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months