[JBoss JIRA] (WFCORE-1088) NPE on a domain server when configuring a deployment logging configuration resource
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1088?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-1088:
----------------------------------
Description:
During the deployment process of a deployment that contains a {{logging.properties}} an NPE is thrown when adding the runtime data to the deployments configuration resource. This seems to only happen on one server, {{server-one}} in the default configuration.
{code}
[Server:server-one] 11:57:09,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 69) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
[Server:server-one] ("deployment" => "batch-jdbc-chunk.war"),
[Server:server-one] ("subsystem" => "logging"),
[Server:server-one] ("configuration" => "default"),
[Server:server-one] ("logger" => "com.arjuna")
[Server:server-one] ]): java.lang.NullPointerException
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$3.updateModel(LoggerResourceDefinition.java:92)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:112)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:55)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
[Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
The above logger {{com.arjuna}} shouldn't even be found as it's not in the deployments logging configuration.
was:
During the deployment process of a deployment that contains a {{logging.properties}} an NPE is thrown when adding the runtime data to the deployments configuration resource. This seems to only happen on one server, {{server-one}} in the default configuration.
{code}
[Server:server-one] 11:57:09,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 69) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
[Server:server-one] ("deployment" => "batch-jdbc-chunk.war"),
[Server:server-one] ("subsystem" => "logging"),
[Server:server-one] ("configuration" => "default"),
[Server:server-one] ("logger" => "com.arjuna")
[Server:server-one] ]): java.lang.NullPointerException
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$3.updateModel(LoggerResourceDefinition.java:92)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:112)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:55)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
[Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
The above logger {{com.arjuna}} shouldn't even be found as it's not in the deployments logging configuration. The runtime subsystem resource doesn't seem to get the correct model or logging configuration in domain mode.
> NPE on a domain server when configuring a deployment logging configuration resource
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-1088
> URL: https://issues.jboss.org/browse/WFCORE-1088
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> During the deployment process of a deployment that contains a {{logging.properties}} an NPE is thrown when adding the runtime data to the deployments configuration resource. This seems to only happen on one server, {{server-one}} in the default configuration.
> {code}
> [Server:server-one] 11:57:09,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 69) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:server-one] ("deployment" => "batch-jdbc-chunk.war"),
> [Server:server-one] ("subsystem" => "logging"),
> [Server:server-one] ("configuration" => "default"),
> [Server:server-one] ("logger" => "com.arjuna")
> [Server:server-one] ]): java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$3.updateModel(LoggerResourceDefinition.java:92)
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:112)
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:55)
> [Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> [Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> [Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
> [Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
> [Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
> [Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> The above logger {{com.arjuna}} shouldn't even be found as it's not in the deployments logging configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1088) NPE on a domain server when configuring a deployment logging configuration resource
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1088?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-1088:
----------------------------------
Description:
During the deployment process of a deployment that contains a {{logging.properties}} an NPE is thrown when adding the runtime data to the deployments configuration resource. This seems to only happen on one server, {{server-one}} in the default configuration.
{code}
[Server:server-one] 11:57:09,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 69) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
[Server:server-one] ("deployment" => "batch-jdbc-chunk.war"),
[Server:server-one] ("subsystem" => "logging"),
[Server:server-one] ("configuration" => "default"),
[Server:server-one] ("logger" => "com.arjuna")
[Server:server-one] ]): java.lang.NullPointerException
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$3.updateModel(LoggerResourceDefinition.java:92)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:112)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:55)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
[Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
The above logger {{com.arjuna}} shouldn't even be found as it's not in the deployments logging configuration. The runtime subsystem resource doesn't seem to get the correct model or logging configuration in domain mode.
was:
During the deployment process of a deployment that contains a {{logging.properties}} an NPE is thrown when adding the runtime data to the deployments configuration resource. This seems to only happen on one server, {{server-one}} in the default configuration.
{code}
[Server:server-one] 11:57:09,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 69) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
[Server:server-one] ("deployment" => "batch-jdbc-chunk.war"),
[Server:server-one] ("subsystem" => "logging"),
[Server:server-one] ("configuration" => "default"),
[Server:server-one] ("logger" => "com.arjuna")
[Server:server-one] ]): java.lang.NullPointerException
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$3.updateModel(LoggerResourceDefinition.java:92)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:112)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:55)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
[Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
The above logger {{com.arjuna}} shouldn't even be found as it's not in the deployments logging configuration.
> NPE on a domain server when configuring a deployment logging configuration resource
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-1088
> URL: https://issues.jboss.org/browse/WFCORE-1088
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> During the deployment process of a deployment that contains a {{logging.properties}} an NPE is thrown when adding the runtime data to the deployments configuration resource. This seems to only happen on one server, {{server-one}} in the default configuration.
> {code}
> [Server:server-one] 11:57:09,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 69) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:server-one] ("deployment" => "batch-jdbc-chunk.war"),
> [Server:server-one] ("subsystem" => "logging"),
> [Server:server-one] ("configuration" => "default"),
> [Server:server-one] ("logger" => "com.arjuna")
> [Server:server-one] ]): java.lang.NullPointerException
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$3.updateModel(LoggerResourceDefinition.java:92)
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:112)
> [Server:server-one] at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:55)
> [Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> [Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> [Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
> [Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
> [Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
> [Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:server-one] at java.lang.Thread.run(Thread.java:745)
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> The above logger {{com.arjuna}} shouldn't even be found as it's not in the deployments logging configuration. The runtime subsystem resource doesn't seem to get the correct model or logging configuration in domain mode.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1088) NPE on a domain server when configuring a deployment logging configuration resource
by James Perkins (JIRA)
James Perkins created WFCORE-1088:
-------------------------------------
Summary: NPE on a domain server when configuring a deployment logging configuration resource
Key: WFCORE-1088
URL: https://issues.jboss.org/browse/WFCORE-1088
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
During the deployment process of a deployment that contains a {{logging.properties}} an NPE is thrown when adding the runtime data to the deployments configuration resource. This seems to only happen on one server, {{server-one}} in the default configuration.
{code}
[Server:server-one] 11:57:09,503 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 69) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
[Server:server-one] ("deployment" => "batch-jdbc-chunk.war"),
[Server:server-one] ("subsystem" => "logging"),
[Server:server-one] ("configuration" => "default"),
[Server:server-one] ("logger" => "com.arjuna")
[Server:server-one] ]): java.lang.NullPointerException
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$3.updateModel(LoggerResourceDefinition.java:92)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggerResourceDefinition$LoggerConfigurationReadStepHandler.updateModel(LoggerResourceDefinition.java:112)
[Server:server-one] at org.jboss.as.logging.deployments.resources.LoggingConfigurationReadStepHandler.execute(LoggingConfigurationReadStepHandler.java:55)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
[Server:server-one] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
[Server:server-one] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
[Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
[Server:server-one] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
[Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:234)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:173)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:136)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:132)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at javax.security.auth.Subject.doAs(Subject.java:360)
[Server:server-one] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:152)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at java.security.AccessController.doPrivileged(Native Method)
[Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:148)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
[Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[Server:server-one] at java.lang.Thread.run(Thread.java:745)
[Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
The above logger {{com.arjuna}} shouldn't even be found as it's not in the deployments logging configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5601) Failure to add a datasource with a name that was previously used
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5601?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-5601:
----------------------------------------
Just to record a synopsis of some chats today. The behavior of reload shouldn't matter. Once the remove op returns successfully, the capability should be removed. It's not, which is a bug, specifically WFCORE-1086.
> Failure to add a datasource with a name that was previously used
> ----------------------------------------------------------------
>
> Key: WFLY-5601
> URL: https://issues.jboss.org/browse/WFLY-5601
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
> Priority: Blocker
> Fix For: 10.0.0.Final
>
>
> Steps to re-create: create DS, remove it, reload and then add again (using the same name for the DS)
> This leads to:
> {noformat}
> java.lang.IllegalStateException: WFLYCTL0363: Capability 'org.wildfly.data-source.swarm-integration-test' is already registered in context 'global'.
> at org.jboss.as.controller.CapabilityRegistry.registerCapability(CapabilityRegistry.java:146)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1422)
> at org.jboss.as.controller.OperationContextImpl.registerCapability(OperationContextImpl.java:1414)
> at org.jboss.as.controller.AbstractAddStepHandler.recordCapabilitiesAndRequirements(AbstractAddStepHandler.java:274)
> at org.jboss.as.controller.AbstractAddStepHandler.execute(AbstractAddStepHandler.java:146)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1087) ManagementResourceRegistration.getOrderedChildTypes() does not account for override models
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1087?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1087:
-------------------------------------
Description:
ManagementResourceRegistration.getOrderedChildTypes() is implemented by simply reading the local state of ConcreteResourceRegistration. It needs to work like getAttributeNames(), by delegating to the root node which in turn uses NodeSubregistry to combine data from any singleton override registration and the corresponding wildcard registration.
Same kind of problem as WFCORE-1086.
was:ManagementResourceRegistration.getCapabilities() is implemented by simply reading the local state of ConcreteResourceRegistration. It needs to work like getAttributeNames(), by delegating to the root node which in turn uses NodeSubregistry to combine data from any singleton override registration and the corresponding wildcard registration.
> ManagementResourceRegistration.getOrderedChildTypes() does not account for override models
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-1087
> URL: https://issues.jboss.org/browse/WFCORE-1087
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.0.CR9
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Blocker
> Fix For: 2.0.0.Final
>
>
> ManagementResourceRegistration.getOrderedChildTypes() is implemented by simply reading the local state of ConcreteResourceRegistration. It needs to work like getAttributeNames(), by delegating to the root node which in turn uses NodeSubregistry to combine data from any singleton override registration and the corresponding wildcard registration.
> Same kind of problem as WFCORE-1086.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1087) ManagementResourceRegistration.getOrderedChildTypes() does not account for override models
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1087:
----------------------------------------
Summary: ManagementResourceRegistration.getOrderedChildTypes() does not account for override models
Key: WFCORE-1087
URL: https://issues.jboss.org/browse/WFCORE-1087
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.CR9
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Blocker
Fix For: 2.0.0.Final
ManagementResourceRegistration.getCapabilities() is implemented by simply reading the local state of ConcreteResourceRegistration. It needs to work like getAttributeNames(), by delegating to the root node which in turn uses NodeSubregistry to combine data from any singleton override registration and the corresponding wildcard registration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-5605) DataSourceDefinition is registering capabilities for deployment tree resources
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-5605:
--------------------------------------
Summary: DataSourceDefinition is registering capabilities for deployment tree resources
Key: WFLY-5605
URL: https://issues.jboss.org/browse/WFLY-5605
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.0.0.CR4
Reporter: Brian Stansberry
Assignee: Jesper Pedersen
The same DataSourceDefinition class is used for registering the MRR for the subsystem=data-sources/(xa-)data-source=* resources and for their equivalents in the /deployment=* tree. In both cases the registerCapabilities() method is recording the datasource capability.
The deployment resources are not actually able to provide the capability[1], so it shouldn't be registered in that case. I believe the DataSourceDefinition.deployed field can be used to turn this off.
[1] Capabilities are management model concepts and can't be provided by services and runtime-only resources. The /deployment=*/subsystem=* resources are runtime-only.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1086) ManagementResourceRegistration.getCapabilities() does not account for override models
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1086:
----------------------------------------
Summary: ManagementResourceRegistration.getCapabilities() does not account for override models
Key: WFCORE-1086
URL: https://issues.jboss.org/browse/WFCORE-1086
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.0.CR9
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Blocker
Fix For: 2.0.0.Final
ManagementResourceRegistration.getCapabilities() is implemented by simply reading the local state of ConcreteResourceRegistration. It needs to work like getAttributeNames(), by delegating to the root node which in turn uses NodeSubregistry to combine data from any singleton override registration and the corresponding wildcard registration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-363:
---------------------------------------
Assignee: Brian Stansberry
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFCORE-1085) Linux and powershell standalone script should be unified in restart logs
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1085?page=com.atlassian.jira.plugi... ]
Marek Kopecký moved JBEAP-1706 to WFCORE-1085:
----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1085 (was: JBEAP-1706)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Scripts
(was: Scripts)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.0.CR8
(was: 7.0.0.DR13 (Alpha))
> Linux and powershell standalone script should be unified in restart logs
> ------------------------------------------------------------------------
>
> Key: WFCORE-1085
> URL: https://issues.jboss.org/browse/WFCORE-1085
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 2.0.0.CR8
> Reporter: Marek Kopecký
> Assignee: Tomaz Cerar
> Priority: Minor
>
> {{:shutdown(restart=true)}} CLI command on linux print "Restarting JBoss..." message on console. On windows with powershell script, this message is not printed. Linux and powershell standalone script should be unified in restart logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month