[JBoss JIRA] (WFCORE-4923) read-resource operation does not resolve expressions recursively
by Tamás Ábele (Jira)
[ https://issues.redhat.com/browse/WFCORE-4923?page=com.atlassian.jira.plug... ]
Tamás Ábele edited comment on WFCORE-4923 at 4/15/20 9:57 AM:
--------------------------------------------------------------
Hi Jeff!
The mentioned one line modification solved the problem for me. Dou you think this can be included in the next release? Should I do a pull or merge request on GITHUB?
was (Author: abele.tamas):
Hi Jeff!
The mention one line modification solved the problem for me. Dou you think this can be included in the next release? Should I do a pull or merge request on GITHUB?
> read-resource operation does not resolve expressions recursively
> ----------------------------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.0.Beta1
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> 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.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (DROOLS-5241) Create archetype for PMML models with drool implementation
by Gabriele Cardosi (Jira)
Gabriele Cardosi created DROOLS-5241:
----------------------------------------
Summary: Create archetype for PMML models with drool implementation
Key: DROOLS-5241
URL: https://issues.redhat.com/browse/DROOLS-5241
Project: Drools
Issue Type: Task
Reporter: Gabriele Cardosi
Assignee: Gabriele Cardosi
The current archetype create module structure for models not using drools.
There is the need for an archetype that creates modules for implementation using drools. Such modules should have slightly different implementation and should be created inside the kie-pmml-models-drools module/directory
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4924) CLI enable-sasl-management doesn't handle "plain-text" attribute
by Michal Petrov (Jira)
[ https://issues.redhat.com/browse/WFCORE-4924?page=com.atlassian.jira.plug... ]
Michal Petrov updated WFCORE-4924:
----------------------------------
Description: When specifying user-properties for a properties realm there is no way to set the "plain-text" sub-attribute. This can result in the "enable-sasl-management" creating a new properties realm instead of using an existing one.
> CLI enable-sasl-management doesn't handle "plain-text" attribute
> ----------------------------------------------------------------
>
> Key: WFCORE-4924
> URL: https://issues.redhat.com/browse/WFCORE-4924
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Michal Petrov
> Assignee: Michal Petrov
> Priority: Major
>
> When specifying user-properties for a properties realm there is no way to set the "plain-text" sub-attribute. This can result in the "enable-sasl-management" creating a new properties realm instead of using an existing one.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4923) read-resource operation does not resolve expressions recursively
by Tamás Ábele (Jira)
[ 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
> read-resource operation does not resolve expressions recursively
> ----------------------------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.0.Beta1
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> 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.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4923) read-resource operation does not resolve expressions recursively
by Tamás Ábele (Jira)
[ 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
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
> read-resource operation does not resolve expressions recursively
> ----------------------------------------------------------------
>
> Key: WFCORE-4923
> URL: https://issues.redhat.com/browse/WFCORE-4923
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 12.0.0.Beta1
> Reporter: Tamás Ábele
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: hal-error1.png, hal-error2.png
>
>
> 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)
6 years
[JBoss JIRA] (WFCORE-4925) Correct GAV versions in ModelTestControllerVersion
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFCORE-4925?page=com.atlassian.jira.plug... ]
Richard Achmatowicz updated WFCORE-4925:
----------------------------------------
Fix Version/s: 12.0.0.Beta2
(was: 11.0.1.Final)
> Correct GAV versions in ModelTestControllerVersion
> --------------------------------------------------
>
> Key: WFCORE-4925
> URL: https://issues.redhat.com/browse/WFCORE-4925
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Beta2
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 12.0.0.Beta2
>
>
> The class org.jboss.as.model.test.ModelTestControllerVersion is used to provide component versioning information for various versions of EAP and Wildfly.
> Given a version of EAP, say, 7.2.0, this class can be used to find the maven version for the product maven artifact, as well the maven version of Wildfly Core artifact used, etc.
> The maven versions for EAP and Wildfly Core use "productized" versions, incorporating the -redhat- tag (e.g. org.wildfly.core:wildfly-threads:6.0.11.Final-redhat-1)
> Currently, ModelTestControllerVersion uses "productized" version numbers for the EAP maven artifact but not for Wildfly Core maven artifact. This means that this class cannot be used to easily specify the maven version for the Wildfly Core component of the EAP version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4925) Correct GAV versions in ModelTestControllerVersion
by Richard Achmatowicz (Jira)
Richard Achmatowicz created WFCORE-4925:
-------------------------------------------
Summary: Correct GAV versions in ModelTestControllerVersion
Key: WFCORE-4925
URL: https://issues.redhat.com/browse/WFCORE-4925
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Affects Versions: 11.0.0.Final
Reporter: Richard Achmatowicz
Assignee: Richard Achmatowicz
Fix For: 11.0.1.Final
The class org.jboss.as.model.test.ModelTestControllerVersion is used to provide component versioning information for various versions of EAP and Wildfly.
Given a version of EAP, say, 7.2.0, this class can be used to find the maven version for the product maven artifact, as well the maven version of Wildfly Core artifact used, etc.
The maven versions for EAP and Wildfly Core use "productized" versions, incorporating the -redhat- tag (e.g. org.wildfly.core:wildfly-threads:6.0.11.Final-redhat-1)
Currently, ModelTestControllerVersion uses "productized" version numbers for the EAP maven artifact but not for Wildfly Core maven artifact. This means that this class cannot be used to easily specify the maven version for the Wildfly Core component of the EAP version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4925) Correct GAV versions in ModelTestControllerVersion
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFCORE-4925?page=com.atlassian.jira.plug... ]
Richard Achmatowicz updated WFCORE-4925:
----------------------------------------
Affects Version/s: 12.0.0.Beta2
(was: 11.0.0.Final)
> Correct GAV versions in ModelTestControllerVersion
> --------------------------------------------------
>
> Key: WFCORE-4925
> URL: https://issues.redhat.com/browse/WFCORE-4925
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Beta2
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 12.0.0.Beta2
>
>
> The class org.jboss.as.model.test.ModelTestControllerVersion is used to provide component versioning information for various versions of EAP and Wildfly.
> Given a version of EAP, say, 7.2.0, this class can be used to find the maven version for the product maven artifact, as well the maven version of Wildfly Core artifact used, etc.
> The maven versions for EAP and Wildfly Core use "productized" versions, incorporating the -redhat- tag (e.g. org.wildfly.core:wildfly-threads:6.0.11.Final-redhat-1)
> Currently, ModelTestControllerVersion uses "productized" version numbers for the EAP maven artifact but not for Wildfly Core maven artifact. This means that this class cannot be used to easily specify the maven version for the Wildfly Core component of the EAP version.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years