[jboss-jira] [JBoss JIRA] (WFCORE-4923) read-resource operation does not resolve expressions recursively

[ https://issues.redhat.com/browse/WFCORE-4923?page=com.atlassian.jira.plug... ] Tamás Ábele updated WFCORE-4923: -------------------------------- Description: The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI. {code:json} [standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true) { "outcome" => "success", "result" => { "restart-jobs-on-resume" => true, "security-domain" => undefined, "default-job-repository" => "in-memory", "default-thread-pool" => "batch", "in-memory-job-repository" => {"in-memory" => {}}, "jdbc-job-repository" => undefined, "thread-factory" => undefined, "thread-pool" => {"batch" => { "active-count" => 0, "completed-task-count" => 0L, "current-thread-count" => 0, "keepalive-time" => { "time" => 30L, "unit" => "SECONDS" }, "largest-thread-count" => 0, "max-threads" => expression "${batch-max-threads}", "name" => "batch", "queue-size" => 0, "rejected-count" => 0, "task-count" => 0L, "thread-factory" => undefined }} } } {code} The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements. The solution would be only adding the {code:java} rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve); {code} line after {code:java} rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults); {code} in the doExecuteInternal method of the \controller\src\main\java\org\jboss\as\controller\operations\global\ReadResourceHandler.java The wildfly console (HAL) source code is also buggy, which when creates an operation like this {code:java} Operation operation = new Operation.Builder(address, READ_RESOURCE_OPERATION) {code} in several places I found does not contain the line {code:java} .param(RESOLVE_EXPRESSIONS, true) {code} and this will cause unresolved expressions to be returned and later numeric error to be thrown while trying to read them. was: The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI. {code:json} [standalone@localhost:9992 /] /subsystem=batch-jberet:read-resource(include-runtime=true,recursive=true,resolve-expressions=true) { "outcome" => "success", "result" => { "restart-jobs-on-resume" => true, "security-domain" => undefined, "default-job-repository" => "in-memory", "default-thread-pool" => "batch", "in-memory-job-repository" => {"in-memory" => {}}, "jdbc-job-repository" => undefined, "thread-factory" => undefined, "thread-pool" => {"batch" => { "active-count" => 0, "completed-task-count" => 0L, "current-thread-count" => 0, "keepalive-time" => { "time" => 30L, "unit" => "SECONDS" }, "largest-thread-count" => 0, "max-threads" => expression "${batch-max-threads}", "name" => "batch", "queue-size" => 0, "rejected-count" => 0, "task-count" => 0L, "thread-factory" => undefined }} } } {code} The missing recursive expression resolvation also causes runtime errors in the wildfly console (HAL) if you use properties your configuration XML-s (standalone.xml, domain.xml, ...) Two examples can be found in the attachements. The solution would be only adding the {code:java} rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve); {code} line after {code:java} rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults); {code} in the doExecuteInternal method of the \controller\src\main\java\org\jboss\as\controller\operations\global\ReadResourceHandler.java The wildfly console (HAL) source code is also buggy -- This message was sent by Atlassian Jira (v7.13.8#713008)