-
Bug
-
Resolution: Done
-
Major
-
12.0.0.Beta1
-
None
The problem affects all versions. The wildfly controller does not resolve expression resursively which causes improper behaviour of the jbos CLI.
[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 }} } }
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
rrOp.get(ModelDescriptionConstants.RESOLVE_EXPRESSIONS).set(resolve);
line after
rrOp.get(ModelDescriptionConstants.INCLUDE_DEFAULTS).set(defaults);
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
Operation operation = new Operation.Builder(address, READ_RESOURCE_OPERATION)
in several places I found does not contain the line
.param(RESOLVE_EXPRESSIONS, true)
and this will cause unresolved expressions to be returned and later numeric error to be thrown while trying to read them.
- is incorporated by
-
-
- Closed
-
- is related to
-
-
- Resolved
-
- relates to
-
-
- Resolved
-
