[JBoss JIRA] (DROOLS-3982) DMN DT Analysis coverage for nested in other decision logic(s)
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-3982:
--------------------------------------
Summary: DMN DT Analysis coverage for nested in other decision logic(s)
Key: DROOLS-3982
URL: https://issues.jboss.org/browse/DROOLS-3982
Project: Drools
Issue Type: Enhancement
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Currently the analysis was performed only when a DT was the decision logic expression of a Decision DRGElement.
Extend the analysis to any DT which could be nested in BKM or in Context /sub-Contexts.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4460) jboss-cli.sh doesn't return json when the output command is 'failed'
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/WFCORE-4460?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFCORE-4460:
-------------------------------
Steps to Reproduce:
Step 1. Restart a JBoss server or host;
Step 2. During the upstart of the server/host, run the command:
{noformat}
/opt/jboss/jboss7_2/jboss-eap-7.2/bin/jboss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
{noformat}
or equivalent for your environment. Notice that the response will NOT be in JSON-format, it will be in the DMR format.
The following output was generated following the above steps:
{noformat}
[tosorio@localhost bin]$ ./jboss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server='*'/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
{
"outcome" => "failed",
"result" => [{
"address" => [
("host" => "master"),
("server" => "server-two"),
("deployment" => "fabrica.war")
],
"outcome" => "failed",
"result" => {
"content" => [{
"hash" => bytes {
0x73, 0xa2, 0x23, 0xaf, 0x5b, 0xb3, 0x3f, 0xc0,
0xaf, 0x84, 0x56, 0x33, 0x99, 0xfb, 0x6c, 0xa6,
0xd1, 0xf1, 0x58, 0x40
},
"archive" => undefined
(...)
"rolled-back" => true
{noformat}
---
However, when the server is completely restarted, the json ouput works properly:
was:
Step 1. Restart a JBoss server or host;
Step 2. During the upstart of the server/host, run the command:
/opt/jboss/jboss7_2/jboss-eap-7.2/bin/jboss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
or equivalent for your environment. Notice that the response will NOT be in JSON-format, it will be in the DMR format.
The following output was generated following the above steps:
{noformat}
[tosorio@localhost bin]$ ./jboss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server='*'/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
{
"outcome" => "failed",
"result" => [{
"address" => [
("host" => "master"),
("server" => "server-two"),
("deployment" => "fabrica.war")
],
"outcome" => "failed",
"result" => {
"content" => [{
"hash" => bytes {
0x73, 0xa2, 0x23, 0xaf, 0x5b, 0xb3, 0x3f, 0xc0,
0xaf, 0x84, 0x56, 0x33, 0x99, 0xfb, 0x6c, 0xa6,
0xd1, 0xf1, 0x58, 0x40
},
"archive" => undefined
(...)
"rolled-back" => true
{noformat}
---
However, when the server is completely restarted, the json ouput works properly:
> jboss-cli.sh doesn't return json when the output command is 'failed'
> --------------------------------------------------------------------
>
> Key: WFCORE-4460
> URL: https://issues.jboss.org/browse/WFCORE-4460
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 9.0.0.Beta4
> Environment: JBoss EAP 7.2.0 running in domain mode.
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Priority: Major
>
> The CLI returns a JSON output just when the CLI command got 'success'. In case of the output 'failed' the output is only DMR syntax.
> The following command was used in the tests:
> JBOSS_HOME/bin/boss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4460) jboss-cli.sh doesn't return json when the output command is 'failed'
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/WFCORE-4460?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFCORE-4460:
-------------------------------
Description:
The CLI returns a JSON output just when the CLI command got 'success'. In case of the output 'failed' the output is only DMR syntax.
The following command was used in the tests:
{noformat}
$JBOSS_HOME/bin/boss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
{noformat}
was:
The CLI returns a JSON output just when the CLI command got 'success'. In case of the output 'failed' the output is only DMR syntax.
The following command was used in the tests:
JBOSS_HOME/bin/boss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
> jboss-cli.sh doesn't return json when the output command is 'failed'
> --------------------------------------------------------------------
>
> Key: WFCORE-4460
> URL: https://issues.jboss.org/browse/WFCORE-4460
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 9.0.0.Beta4
> Environment: JBoss EAP 7.2.0 running in domain mode.
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Priority: Major
>
> The CLI returns a JSON output just when the CLI command got 'success'. In case of the output 'failed' the output is only DMR syntax.
> The following command was used in the tests:
> {noformat}
> $JBOSS_HOME/bin/boss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4460) jboss-cli.sh doesn't return json when the output command is 'failed'
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/WFCORE-4460?page=com.atlassian.jira.plugi... ]
Ingo Weiss updated WFCORE-4460:
-------------------------------
Steps to Reproduce:
Step 1. Restart a JBoss server or host;
Step 2. During the upstart of the server/host, run the command:
/opt/jboss/jboss7_2/jboss-eap-7.2/bin/jboss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
or equivalent for your environment. Notice that the response will NOT be in JSON-format, it will be in the DMR format.
The following output was generated following the above steps:
{noformat}
[tosorio@localhost bin]$ ./jboss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server='*'/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
{
"outcome" => "failed",
"result" => [{
"address" => [
("host" => "master"),
("server" => "server-two"),
("deployment" => "fabrica.war")
],
"outcome" => "failed",
"result" => {
"content" => [{
"hash" => bytes {
0x73, 0xa2, 0x23, 0xaf, 0x5b, 0xb3, 0x3f, 0xc0,
0xaf, 0x84, 0x56, 0x33, 0x99, 0xfb, 0x6c, 0xa6,
0xd1, 0xf1, 0x58, 0x40
},
"archive" => undefined
(...)
"rolled-back" => true
{noformat}
---
However, when the server is completely restarted, the json ouput works properly:
was:
Step 1. Restart a JBoss server or host;
Step 2. During the upstart of the server/host, run the command:
/opt/jboss/jboss7_2/jboss-eap-7.2/bin/jboss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
or equivalent for your environment. Notice that the response will NOT be in JSON-format, it will be in the DMR format.
The following output was generated following the above steps:
[tosorio@localhost bin]$ ./jboss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server='*'/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
{
"outcome" => "failed",
"result" => [{
"address" => [
("host" => "master"),
("server" => "server-two"),
("deployment" => "fabrica.war")
],
"outcome" => "failed",
"result" => {
"content" => [{
"hash" => bytes {
0x73, 0xa2, 0x23, 0xaf, 0x5b, 0xb3, 0x3f, 0xc0,
0xaf, 0x84, 0x56, 0x33, 0x99, 0xfb, 0x6c, 0xa6,
0xd1, 0xf1, 0x58, 0x40
},
"archive" => undefined
(...)
"rolled-back" => true
---
However, when the server is completely restarted, the json ouput works properly:
> jboss-cli.sh doesn't return json when the output command is 'failed'
> --------------------------------------------------------------------
>
> Key: WFCORE-4460
> URL: https://issues.jboss.org/browse/WFCORE-4460
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 9.0.0.Beta4
> Environment: JBoss EAP 7.2.0 running in domain mode.
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Priority: Major
>
> The CLI returns a JSON output just when the CLI command got 'success'. In case of the output 'failed' the output is only DMR syntax.
> The following command was used in the tests:
> JBOSS_HOME/bin/boss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required
by Michal Petrov (Jira)
[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ]
Michal Petrov reassigned WFCORE-2252:
-------------------------------------
Assignee: Michal Petrov
> AttributeDefinition should reject configs with a default value that are also set as required
> --------------------------------------------------------------------------------------------
>
> Key: WFCORE-2252
> URL: https://issues.jboss.org/browse/WFCORE-2252
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Michal Petrov
> Priority: Major
>
> If an AttributeDefinition has a default value configured, then the 'required' setting should be false. The default removes the requirement that the user configure a value.
> AttributeDefinition should reject the combination of a default value and required=true in its constructor.
> I found 13 attributes not following this in subsystem=eltyron (see WFLY-8004) and there are probably more in other subsystems. WFCORE-2249 has been somewhat hiding this for fields in complex attributes because the 2249 bug meant things were not getting validated that should have been.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFCORE-4460) jboss-cli.sh doesn't return json when the output command is 'failed'
by Ingo Weiss (Jira)
[ https://issues.jboss.org/browse/WFCORE-4460?page=com.atlassian.jira.plugi... ]
Ingo Weiss moved JBEAP-16870 to WFCORE-4460:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-4460 (was: JBEAP-16870)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: 9.0.0.Beta4
(was: 7.2.0.GA)
> jboss-cli.sh doesn't return json when the output command is 'failed'
> --------------------------------------------------------------------
>
> Key: WFCORE-4460
> URL: https://issues.jboss.org/browse/WFCORE-4460
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 9.0.0.Beta4
> Environment: JBoss EAP 7.2.0 running in domain mode.
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Priority: Major
>
> The CLI returns a JSON output just when the CLI command got 'success'. In case of the output 'failed' the output is only DMR syntax.
> The following command was used in the tests:
> JBOSS_HOME/bin/boss-cli.sh --connect --controller=localhost:9990 --command="/host=*/server=*/deployment=*/:read-resource(recursive=false,include-runtime=true)" --output-json
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12019) Cannot remove a undertow server resource at one time
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12019?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFLY-12019:
-----------------------------------------
[~spyrkob] FWIW, I just noticed this:
{code}
[standalone@embedded /] /subsystem=undertow/server=default-server/host=default-host:read-operation-description(name=remove)
{
"outcome" => "success",
"result" => {
"operation-name" => "remove",
"description" => "Removes a host",
"request-properties" => {},
"reply-properties" => {},
"read-only" => false,
"restart-required" => "all-services",
"runtime-only" => false
}
}
{code}
"restart-required" => "all-services"
IOW, the entire HostRemove handler is one big bug. It should not be removing services when its description says it won't. The resource can use ReloadRequiredRemoveStepHandler.
If that were changed, because the remove ops for filter-ref and single-sign-on child resources declare they do support removing services if allow-resource-service-restart=true is true is set, you can get some mixed behavior due to WFCORE-1483 if this is invoked:
/subsystem=undertow/server=default-server/host=test-host:remove{allow-resource-service-restart=true}
The services associated with the filter-ref and sso children will be removed while the other services associated with the resource tree will remain.
That's a corner case though, and really allow-resource-service-restart=true is an expert setting where the user declares they understand what they are doing.
> Cannot remove a undertow server resource at one time
> ----------------------------------------------------
>
> Key: WFLY-12019
> URL: https://issues.jboss.org/browse/WFLY-12019
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 16.0.0.Final
> Reporter: Bartosz Spyrko
> Assignee: Bartosz Spyrko
> Priority: Major
>
> Cannot remove a server attribute.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.undertow.server.default-server.default-host was depended upon by service jboss.undertow.server.default-server.default-host.filter-ref.x-powered-by-header, service jboss.undertow.server.default-server.default-host.location.
> /, service jboss.undertow.server.default-server.default-host.filter-ref.server-header",
> "rolled-back" => true,
> "response-headers" => undefined
> }
> {noformat}
> However, it can be removed executing same command again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-6892) Access logging for EJBs
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-6892?page=com.atlassian.jira.plugin.... ]
Cheng Fang updated WFLY-6892:
-----------------------------
Labels: EAP-CD17 affects_elytron (was: affects_elytron)
> Access logging for EJBs
> -----------------------
>
> Key: WFLY-6892
> URL: https://issues.jboss.org/browse/WFLY-6892
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Brad Maxwell
> Assignee: Cheng Fang
> Priority: Major
> Labels: EAP-CD17, affects_elytron
> Fix For: 17.0.0.Beta1
>
>
> Access logging for EJB requests similar to Web access logging would be very useful.
> Possibly something like:
> {code}
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] [invocation id] Request Received ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Starting Invocation ...
> [date-time] [host/IP of caller] [EJB Name] [EJB Method] invocation id] Finished Invocation ...
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months