[JBoss JIRA] (WFCORE-323) Validate composite operation steps just before executing them
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-323?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-323:
------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3259
> Validate composite operation steps just before executing them
> -------------------------------------------------------------
>
> Key: WFCORE-323
> URL: https://issues.jboss.org/browse/WFCORE-323
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: EAP
>
> Say we have a composite operation with 2 steps:
> 1) /extension=org.jboss.as.messaging:add
> 2) /subsystem=messaging:add
> This will fail:
> Failed to execute batch: JBAS014739: No handler for add at address
> [("subsystem" => "messaging")]
> This fails because at the time of validation the /subsystem=messaging:add is not valid.
> To illustrate, the execution order is
> Validate 1-2
> 1
> 2
> A possible solution is to convert this to the following:
> V1
> 1
> V2 (works now because 1 has registered the subsystem API)
> 2
> I think that should work but it's a very complex area, particularly in a managed domain, so it's not at all certain this would prove feasible.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 6 months
[JBoss JIRA] (WFCORE-2252) AttributeDefinition should reject configs with a default value that are also set as required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2252?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2252:
------------------------------------------
I have a number of "WIP" branches that have been sitting inactive for a long time and I'm linking them to the related issues in case the work on them is useful. For this one:
https://github.com/bstansberry/wildfly-core/tree/WFCORE-2252
> 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
>
> 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.5.0#75005)
5 years, 6 months
[JBoss JIRA] (WFCORE-1781) DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1781?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1781:
------------------------------------------
I have a number of "WIP" branches that have been sitting inactive for a long time and I'm linking them to the related issues in case the work on them is useful. For this one:
https://github.com/bstansberry/wildfly-core/tree/WFCORE-1781
> DomainModelControllerService is installing the management request handlers for DC-related requests for slaves using cached-dc
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1781
> URL: https://issues.jboss.org/browse/WFCORE-1781
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Labels: domain-mode
>
> The DomainModelControllerService code block that parses a local domain.xml is also installing the service the allows the management interface to accept requests that uses the request headers meant for the master side slave->master intra-domain communications. This service should not be added in the slave using cached-dc case, but it is now.
> It also shouldn't be added if the DC is running admin-only.
> OTOH in all cases where it is not added, a different service should be added that will reject any slave registration requests that come in with the correct error codes that the slave knows how to parse. Currently that rejection is only happening for admin-only masters or slaves that are using cached-dc, which is not correct.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 6 months
[JBoss JIRA] (DROOLS-3054) Highlight in expression builder previous selection in Scenario right panel
by Daniele Zonca (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3054?page=com.atlassian.jira.plugi... ]
Daniele Zonca commented on DROOLS-3054:
---------------------------------------
[~uxdlc]
One question for you.
Scenario:
- user map a column "Test" to field Person.name
- user does other activities and then he would like to edit column "Test" so left click again
- there is no place in expression builder component where he can see the existing mapping to Person.name
I think we can highlight in some way (blue background?) in the expression builder the old value.
What do you suggest?
> Highlight in expression builder previous selection in Scenario right panel
> --------------------------------------------------------------------------
>
> Key: DROOLS-3054
> URL: https://issues.jboss.org/browse/DROOLS-3054
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Gabriele Cardosi
> Priority: Minor
>
> When the user edits the type of a column, the expression builder into the right panel should highlight the existing mapped type.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 6 months
[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1649:
------------------------------------------
I have a number of "WIP" branches that have been sitting inactive for a long time and I'm linking them to the related issues in case the work on them is useful. For this one:
https://github.com/bstansberry/wildfly-core/tree/WFCORE-1649
> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1649
> URL: https://issues.jboss.org/browse/WFCORE-1649
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Labels: domain-mode
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 6 months
[JBoss JIRA] (WFCORE-1220) Try closing the channel if java.lang.Error prevents sending error responses to the client
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1220?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1220:
------------------------------------------
I have a number of "WIP" branches that have been sitting inactive for a long time and I'm linking them to the related issues in case the work on them is useful. For this one:
https://github.com/bstansberry/wildfly-core/tree/WFCORE-1220
> Try closing the channel if java.lang.Error prevents sending error responses to the client
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-1220
> URL: https://issues.jboss.org/browse/WFCORE-1220
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Management
> Reporter: Brian Stansberry
> Labels: domain-mode
>
> Beyond the basic work on WFCORE-1134, look into further reaction when Errors occur and the server or HC cannot even send an error response to the caller. If we get to this point, the task has already failed to handle a problem and now we can't notify the remote side either. Most likely this is an OOME situation, although any Error here means a major issue.
> Options:
> 1) Try and close the channel to disconnect this process from the remote end so it doesn't disrupt the remote end. If this is an intra-HC or HC-server connection a successful close will remove this process from normal domain control. If this is a server the HC still has some control over the server via the ProcessController, e.g. to handle a 'kill' or 'destroy' management op. If this is a slave HC, the slave is disconnected from the domain. Either a server or a slave HC may try to reconnect, although it's likely better if that fails and the user just restarts the process.
> If the remote side is an end user client (e.g. CLI) then a successful close will be noticed by the client. The user can reconnect or take action to terminate this process.
> 2) Commit suicide via SystemExiter.exit. But I'm not certain complete termination of the process is how we want to deal with problems with management requests. Probably some sort of configurable policy would be better.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 6 months
[JBoss JIRA] (DROOLS-3041) [DMN Designer] Can not edit node after diagram cleared
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3041?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-3041:
-----------------------------------
Story Points: 2
Sprint: 2018 Week 39-41
> [DMN Designer] Can not edit node after diagram cleared
> ------------------------------------------------------
>
> Key: DROOLS-3041
> URL: https://issues.jboss.org/browse/DROOLS-3041
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn, Screenshot from 2018-09-26 13-18-33.png
>
>
> If user clears the diagram and then add new node, he is unable to edit this node.
> h2. Acceptance test
> h3. New diagram
> - Add nodes
> - Clear
> - Add new decision node
> - Put some expression inside
> h3. Non empty existing diagram
> - Clear
> - Add new decision node
> - Put some expression inside
> - Save reopen
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 6 months
[JBoss JIRA] (DROOLS-3041) [DMN Designer] Can not edit node after diagram cleared
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3041?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3041:
----------------------------------------
{{DecisionNavigatorObserver.onCanvasClear(..)}} observes the {{CanvasClearEvent}}.
This causes {{DecisionNavigatorPresenter.removeAllElements()}} to be invoked that (unsurprisingly) removes all elements from the Decision Navigator. Consequentially when {{DecisionNavigatorObserver.onNestedElementAdded(..)}} executes in response to the Expression Type being changed there is no active parent node found in {{DecisionNavigatorTreePresenter.getActiveParent()}} leading to the NPE.
> [DMN Designer] Can not edit node after diagram cleared
> ------------------------------------------------------
>
> Key: DROOLS-3041
> URL: https://issues.jboss.org/browse/DROOLS-3041
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn, Screenshot from 2018-09-26 13-18-33.png
>
>
> If user clears the diagram and then add new node, he is unable to edit this node.
> h2. Acceptance test
> h3. New diagram
> - Add nodes
> - Clear
> - Add new decision node
> - Put some expression inside
> h3. Non empty existing diagram
> - Clear
> - Add new decision node
> - Put some expression inside
> - Save reopen
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 6 months
[JBoss JIRA] (WFLY-11089) Uploading content from HAL in SSL doesn't work
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-11089?page=com.atlassian.jira.plugin... ]
Claudio Miranda updated WFLY-11089:
-----------------------------------
Attachment: https_webcons.jks
> Uploading content from HAL in SSL doesn't work
> ----------------------------------------------
>
> Key: WFLY-11089
> URL: https://issues.jboss.org/browse/WFLY-11089
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow), Web Console
> Affects Versions: 14.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
> Attachments: application-roles.properties, https_webcons.jks, localhost.har, standalone.xml, truststore.jks, windows2008-1.gsslab.rdu2.redhat.com.jks
>
>
> When uploading a file from the web console to WildFly using an SSL secured connection the content is not stored, it is replaced by the Base64 DMR operation.
> Looking at the request I didn't see the file part of the multipart request the parsing return only 1 part while the request on management-upload seems to have 2 parts (see attached har file).
> It doesn't happen with the jboss-cli (ssl or not) nor in HAL on HTTP.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
5 years, 6 months