[JBoss JIRA] (WFCORE-3339) [GSS](7.2.0) Management returning success for read-attribute on non-existant path
by Brad Maxwell (JIRA)
Brad Maxwell created WFCORE-3339:
------------------------------------
Summary: [GSS](7.2.0) Management returning success for read-attribute on non-existant path
Key: WFCORE-3339
URL: https://issues.jboss.org/browse/WFCORE-3339
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 3.0.4.Final
Reporter: Brad Maxwell
Assignee: Brian Stansberry
In Wildfly, a command such as this with a non-existent path returns success instead of failed:
{code}
/host=master/server=nonExistant:read-attribute(name=runtime-configuration-state)
{
"outcome" => "success",
"result" => "stopped"
}
{code}
Where as in EAP 6.4:
{code}
[domain@localhost:9999 /] /host=master/server=server-NOT-EXIST:read-attribute(name=server-state)
Failed to get the list of the operation properties: "JBAS014883: No resource definition is registered for address [
("host" => "master"),
("server" => "server-NOT-EXIST")
]"
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-3337:
---------------------------------------
For some reason I thought capabilities required services. If that's not that case that would probably work quite well and give a more standard error message.
> Logging resources shouldn't be allowed to removed if they are in-use
> --------------------------------------------------------------------
>
> Key: WFCORE-3337
> URL: https://issues.jboss.org/browse/WFCORE-3337
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
> Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3337:
------------------------------------------
Never mind, kind of. You want to check the original thing being removed and trigger reload-required instead of removing, which is a different thing. The WFCORE-1106 thing might then be useful to prevent subsequent config changes that might assume the removed things is gone from taking effect. But that's a further step.
> Logging resources shouldn't be allowed to removed if they are in-use
> --------------------------------------------------------------------
>
> Key: WFCORE-3337
> URL: https://issues.jboss.org/browse/WFCORE-3337
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
> Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3337?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3337:
------------------------------------------
Capabilities and requirements can do this for you if the relationships between things are tracked via caps/reqs. See discussion of WFCORE-1106.
> Logging resources shouldn't be allowed to removed if they are in-use
> --------------------------------------------------------------------
>
> Key: WFCORE-3337
> URL: https://issues.jboss.org/browse/WFCORE-3337
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
>
> Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
> Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3337) Logging resources shouldn't be allowed to removed if they are in-use
by James Perkins (JIRA)
James Perkins created WFCORE-3337:
-------------------------------------
Summary: Logging resources shouldn't be allowed to removed if they are in-use
Key: WFCORE-3337
URL: https://issues.jboss.org/browse/WFCORE-3337
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Currently you can remove a logging resource even if it's used by another resource. An example of this would be the ability to remove a formatter even though that formatter is attached to a handler. Removing handlers does validate it's not attached to a logger first. However all logging resources should do this.
Note that logging does not use services which is why this needs to be manually checked. This should be doable via the configuration API. Note too that a fix to validate this will also be done in the logmanager, LOGMGR-179.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (LOGMGR-179) The configuration API should fail if a configuration being removed is attached to another configuration
by James Perkins (JIRA)
James Perkins created LOGMGR-179:
------------------------------------
Summary: The configuration API should fail if a configuration being removed is attached to another configuration
Key: LOGMGR-179
URL: https://issues.jboss.org/browse/LOGMGR-179
Project: JBoss Log Manager
Issue Type: Bug
Reporter: James Perkins
Assignee: James Perkins
The configuration API will allow the removal of a configuration resource even if that resource is attached to a different configuration. For example you can remove a {{FormatterConfiguration}} even if that formatter is attached to a {{HandlerConfiguration}}. This should be validated and fail if prepared or committed via the {{LogContextConfiguration}} API.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9405) NPE when trying to remove an EJB subsystem channel-creation-options resource
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9405?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-9405:
-----------------------------------
Summary: NPE when trying to remove an EJB subsystem channel-creation-options resource (was: NPE when trying to recursively remove the EJB subsystem)
> NPE when trying to remove an EJB subsystem channel-creation-options resource
> ----------------------------------------------------------------------------
>
> Key: WFLY-9405
> URL: https://issues.jboss.org/browse/WFLY-9405
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> This fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> with this in the server log:
> {code}
> 15:53:42,572 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("remove") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote"),
> ("channel-creation-options" => "MAX_OUTBOUND_MESSAGES")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:894)
> at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:884)
> at org.jboss.as.controller.RestartParentResourceHandlerBase.getModel(RestartParentResourceHandlerBase.java:216)
> at org.jboss.as.controller.RestartParentResourceHandlerBase.access$000(RestartParentResourceHandlerBase.java:39)
> at org.jboss.as.controller.RestartParentResourceHandlerBase$1.execute(RestartParentResourceHandlerBase.java:66)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> ...
> {code}
> I believe a post-boot add of this resource would fail as well.
> Problem is ChannelCreationOptionRemove and ChannelCreationOptionAdd in RemoteConnectorChannelCreationOptionResource use an incorrect parentKeyName. These handlers extend RestartParentResourceHandlerBase but are passing the *value* of the parent element as "parentKeyName" instead of its *key*; i.e. "remote" instead of "service".
> Even though this code has been like this since 2012, this is somewhat a regression since before the current version our standard configs did not include resources of this type. So users could hit this in previous releases but now they are more likely to.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFLY-9405) NPE when trying to recursively remove the EJB subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9405?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-9405:
----------------------------------------
The description does a recursive removal of the entire ejb3 subsystem to cause this, but that's not necessary. A targeted op would do it too:
{code}
[standalone@embedded /] /subsystem=ejb3/service=remote/channel-creation-options=MAX_OUTBOUND_MESSAGES:remove
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
"rolled-back" => true
}
{code}
For this to fail the server can't be running in --admin-only (hence the workaround I posted.)
> NPE when trying to recursively remove the EJB subsystem
> -------------------------------------------------------
>
> Key: WFLY-9405
> URL: https://issues.jboss.org/browse/WFLY-9405
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> This fails:
> {code}
> [standalone@localhost:9990 /] /subsystem=ejb3:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.NullPointerException",
> "rolled-back" => true
> }
> {code}
> with this in the server log:
> {code}
> 15:53:42,572 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("remove") failed - address: ([
> ("subsystem" => "ejb3"),
> ("service" => "remote"),
> ("channel-creation-options" => "MAX_OUTBOUND_MESSAGES")
> ]): java.lang.NullPointerException
> at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:894)
> at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:884)
> at org.jboss.as.controller.RestartParentResourceHandlerBase.getModel(RestartParentResourceHandlerBase.java:216)
> at org.jboss.as.controller.RestartParentResourceHandlerBase.access$000(RestartParentResourceHandlerBase.java:39)
> at org.jboss.as.controller.RestartParentResourceHandlerBase$1.execute(RestartParentResourceHandlerBase.java:66)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:980)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> ...
> {code}
> I believe a post-boot add of this resource would fail as well.
> Problem is ChannelCreationOptionRemove and ChannelCreationOptionAdd in RemoteConnectorChannelCreationOptionResource use an incorrect parentKeyName. These handlers extend RestartParentResourceHandlerBase but are passing the *value* of the parent element as "parentKeyName" instead of its *key*; i.e. "remote" instead of "service".
> Even though this code has been like this since 2012, this is somewhat a regression since before the current version our standard configs did not include resources of this type. So users could hit this in previous releases but now they are more likely to.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3336:
----------------------------------
Steps to Reproduce:
1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration)
2. Deploy both EAR files and access them
3. Check log files.
*Note:* The following reproducer only works on WildFly Full, but the issue itself is likely in WIldFly Core.
To reproduce with the attached {{logging-profile.zip}} do the follow:
# Build the project and deploy the EAR.
## With maven you can do {{mvn clean isntall && cd ear && mvn wildfly:deploy -Pconfigure-logging}}
# In a browser go to http://localhost:8080/test-war-one/rest/log
# Next go to http://localhost:8080/test-war-two/rest/log, here you'll see less log messages
# Now if you go to http://localhost:8080/test-war-one/rest/read you'll see a mix of log messages from both WAR's
was:
1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration)
2. Deploy both EAR files and access them
3. Check log files.
To reproduce with the attached {{logging-profile.zip}} do the follow:
# Build the project and deploy the EAR.
## With maven you can do {{mvn clean isntall && cd ear && mvn wildfly:deploy -Pconfigure-logging}}
# In a browser go to http://localhost:8080/test-war-one/rest/log
# Next go to http://localhost:8080/test-war-two/rest/log, here you'll see less log messages
# Now if you go to http://localhost:8080/test-war-one/rest/read you'll see a mix of log messages from both WAR's
> Not able to separate application(EAR) logging with the use of logging profile
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3336
> URL: https://issues.jboss.org/browse/WFCORE-3336
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: 01933631-new.tar.gz, logging-profile.zip
>
>
> Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file.
> WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log.
> when we access application we can see logging from EAR1 into EAR2 log file .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3336) Not able to separate application(EAR) logging with the use of logging profile
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3336?page=com.atlassian.jira.plugi... ]
James Perkins updated WFCORE-3336:
----------------------------------
Steps to Reproduce:
1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration)
2. Deploy both EAR files and access them
3. Check log files.
To reproduce with the attached {{logging-profile.zip}} do the follow:
# Build the project and deploy the EAR.
## With maven you can do {{mvn clean isntall && cd ear && mvn wildfly:deploy -Pconfigure-logging}}
# In a browser go to http://localhost:8080/test-war-one/rest/log
# Next go to http://localhost:8080/test-war-two/rest/log, here you'll see less log messages
# Now if you go to http://localhost:8080/test-war-one/rest/read you'll see a mix of log messages from both WAR's
was:
1. Start server instance with attached standalone.xml file(Logging subsystem contains logger-profile configuration)
2. Deploy both EAR files and access them
3. Check log files.
> Not able to separate application(EAR) logging with the use of logging profile
> -----------------------------------------------------------------------------
>
> Key: WFCORE-3336
> URL: https://issues.jboss.org/browse/WFCORE-3336
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Attachments: 01933631-new.tar.gz, logging-profile.zip
>
>
> Two ear files are deployed on EAP instance and both are configured to use different logging profile through EAR/META-INF/MANIFEST.MF file.
> WAR file from EAR uses some libraries those are present in the "lib" folder of each ear file. Application1.ear which logs in app1.log and Application2.ear which logs in app2.log.
> when we access application we can see logging from EAR1 into EAR2 log file .
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 1 month