Description of problem: Adding an access-log pattern appears to impact sso resource config Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1) cd /profile=ha/subsystem=web/virtual-server=default-host/sso and then run the command read-resource. Output is { "outcome" => "success", "result" => { "alias" => [ "localhost", "example.com" ], "default-web-module" => "ROOT.war", "enable-welcome-root" => true, "name" => "default-host", "access-log" => undefined, "configuration" => undefined, "rewrite" => undefined, "sso" => undefined 2) Add a log pattern using the command /profile=ha/subsystem=web/virtual-server=default-host/access-log=configuration:add(pattern="%T %h %l %u %t %r %s %b %{COOKIE}i %{SET-COOKIE}o") the output of the command /profile=ha/subsystem=web/virtual-server=default-host:read-resource becomes ----8<------------------ { "outcome" => "success", "result" => { "alias" => [ "localhost", "example.com" ], "default-web-module" => "ROOT.war", "enable-welcome-root" => true, "name" => "default-host", "access-log" => {"configuration" => undefined}, "configuration" => {"access-log" => undefined}, "rewrite" => undefined, "sso" => {"configuration" => undefined} } ----8<------------------ 2.1) sso should still be **"sso" => undefined** but it has **"sso" => {"configuration" => undefined}** 2.2) access log has two entries "access-log" => {"configuration" => undefined}, "configuration" => {"access-log" => undefined}, 3) Adding recursive option omits sso from the output. /profile=ha/subsystem=web/virtual-server=default-host:read-resource(recursive=true) { "outcome" => "success", "result" => { "alias" => [ "localhost", "example.com" ], "default-web-module" => "ROOT.war", "enable-welcome-root" => true, "name" => "default-host", "configuration" => {"access-log" => { "extended" => false, "pattern" => "%T %h %l %u %t %r %s %b %{COOKIE}i %{SET-COOKIE}o", "prefix" => "access_log.", "resolve-hosts" => false, "rotate" => true, "directory" => undefined, "setting" => undefined }}, "rewrite" => undefined 3.1) sso is missing from the output above 4) Run the following sequence of commands ---8<------------------ [domain@labbox:9999 /] cd /profile=ha/subsystem=web/virtual-server=default-host [domain@labbox:9999 virtual-server=default-host] ls access-log rewrite alias=["localhost","example.com"] enable-welcome-root=true configuration sso default-web-module=ROOT.war name=default-host [domain@labbox:9999 virtual-server=default-host] cd access-log= [domain@1labbox:9999 access-log] ls configuration [domain@labbox:9999 access-log] cd configuration JBAS014808: Child resource '"access-log" => "configuration"' not found [domain@1labbox:9999 access-log] [domain@1labbox:9999 access-log] cd ../ [domain@labbox:9999 virtual-server=default-host] cd sso= [domain@labbox:9999 sso] [domain@labbox:9999 sso] ls configuration [domain@labbox:9999 sso] cd configuration JBAS014808: Child resource '"sso" => "configuration"' not found [domain@labbox:9999 sso] ls -l configuration ---8<------------------ 4.1) sso dir is showing configuration which is wrong. If try to 'cd configuration' you get error JBAS014808 . 4.2) access-log dir contains configuration. If try to 'cd configuration' you get error JBAS014808 . Actual results: Expected results: 1) access-log config should not impact sso cli read-resource output 2) access log should not have conflicting/confusing entries 3) adding recursive to the read-resource command should include all attributes Additional info:
Making it Domain Management. This looks to be related to the use of backward-compatible aliases for old config styles from AS 7.0. The access-log=configuration and sso=configuration variants are aliases to the correct configuration=. Some details: 2.1) sso should still be **"sso" => undefined** but it has **"sso" => {"configuration" => undefined}** Yes, this is odd. 2.2) access log has two entries "access-log" => {"configuration" => undefined}, "configuration" => {"access-log" => undefined}, I believe the default setting for read-resource is not to show aliases, show yes, having both appear seems wrong. You would expect both if you wanted to see aliases. 3) Adding recursive option omits sso from the output. This is a nice clue to where the 2.1/2.2 problems lie since this code path seems to fix the issue. 4.1) sso dir is showing configuration which is wrong. If try to 'cd configuration' you get error JBAS014808 . 4.2) access-log dir contains configuration. If try to 'cd configuration' you get error JBAS014808 . Yes, this is wrong.
I don't thing this is an issue, given the way how aliases work. Only thing worth checking is why do we display aliases for :read-resource by default even when aliases=true is not set. They should not be displayed by default in any case. it works properly for recursive read resource but not for default one.
Adding dev_ack+ flag to check / verify behavior of :read-resource in aspect of when and why are aliases included in output.
Changing to dev_ack- as the jboss‑eap‑6.3.0? flag is the relevant one. Next I'll switch it to 6.4 and re-ack.
PR : https://github.com/jbossas/jboss-eap/pull/1892 Upstream already merged
I just want to make a little summary for this BZ. We are fixing the behaviour of r-r-d and r-ch-t operations (as described in WFCORE-57) not to show aliases unless include-aliases is set to true. If https://access.redhat.com/support/cases/#/case/01044483 is not considered to be bug then we should close it and notify customer as I see exactly the same behaviour (https://access.redhat.com/solutions/735753) with EAP 6.4.0.DR9. I am just wondering if /profile=ha/subsystem=web/virtual-server=default-host:read-resource(recursive=true) don't show sso why /profile=ha/subsystem=web/virtual-server=default-host:read-resource(include-aliases=false does? ------ There seems to be another hidden bug in web subsystem, try on clear server: /profile=ha/subsystem=web/virtual-server=default-host:read-resource(recursive=true, include-aliases=true) { "outcome" => "success", ... /profile=ha/subsystem=web/virtual-server=default-host/access-log=configuration:add(pattern="%T %h %l %u %t %r %s %b %{COOKIE}i %{SET-COOKIE}o") { "outcome" => "success", ... /profile=ha/subsystem=web/virtual-server=default-host:read-resource(recursive=true, include-aliases=true) { "outcome" => "failed", "rolled-back" => true } Can you please check it out?
This fix only concerned the Read resource description. Those configuration attributes won't show if you do a: /profile=ha/subsystem=web/virtual-server=default-host:read-resource-description
Sorry, I think the problem is that the alias is configuration=sso and not just configuration while the registered child being tested is configuration.
Upstream PR : https://github.com/wildfly/wildfly-core/pull/366 PR: https://github.com/jbossas/jboss-eap/pull/2077
If I understand this correctly, 'read-children-types' operation is still broken: /profile=ha/subsystem=web/virtual-server=default-host:read-resource-description ... "children" => { "configuration" => { "description" => "configuration of virutal server", "model-description" => undefined }, "rewrite" => { "description" => "A list of rewrite rules that will be processed in order on the URL or vhost specified in the request.", "model-description" => undefined } } ... /profile=ha/subsystem=web/virtual-server=default-host:read-children-types { "outcome" => "success", "result" => [ "access-log", "configuration", "rewrite", "sso" ] }
PR: https://github.com/jbossas/jboss-eap/pull/2149
Verified on EAP 6.4.0.ER1