[JBoss JIRA] (DROOLS-2272) [DMN Editor] Move Editor controls inline
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2272?page=com.atlassian.jira.plugi... ]
Michael Anstis updated DROOLS-2272:
-----------------------------------
Description:
Expression Editors have a row of controls to add row, column, change Hit Policy etc.
These all need moving "inline" into the editor itself. -The content of the new context menu will be driven by the cell in the Expression grid that was (single) clicked. Double click continues to edit the cell.-
*New requirements*
* Context menu (single right-click) to provide the ability to cut/copy/paste/insert (row/column)/delete (row/column)/delete cell value
* Double -Single- left-click to edit a cells content (this could be an {{TextBox}} or a {{ListBox}} or a more sophisticated editor).
* Context menu entries are reflected in the state of the toolbar (menubar, whatever) in the workbench.
This means the "Undefined Expression selector" ([DROOLS-2296|https://issues.jboss.org/browse/DROOLS-2296]), "Context Editor" ([DROOLS-2297|https://issues.jboss.org/browse/DROOLS-2297]) and "Relation Editor" ([DROOLS-2299|https://issues.jboss.org/browse/DROOLS-2299]) will need refactoring.
was:
Expression Editors have a row of controls to add row, column, change Hit Policy etc.
These all need moving "inline" into the editor itself. -The content of the new context menu will be driven by the cell in the Expression grid that was (single) clicked. Double click continues to edit the cell.-
*New requirements*
* Context menu (single right-click) to provide the ability to cut/copy/paste/insert (row/column)/delete (row/column)/delete cell value
* Single left-click to edit a cells content (this could be an {{TextBox}} or a {{ListBox}} or a more sophisticated editor).
* Context menu entries are reflected in the state of the toolbar (menubar, whatever) in the workbench.
This means the "Undefined Expression selector" ([DROOLS-2296|https://issues.jboss.org/browse/DROOLS-2296]), "Context Editor" ([DROOLS-2297|https://issues.jboss.org/browse/DROOLS-2297]) and "Relation Editor" ([DROOLS-2299|https://issues.jboss.org/browse/DROOLS-2299]) will need refactoring.
> [DMN Editor] Move Editor controls inline
> ----------------------------------------
>
> Key: DROOLS-2272
> URL: https://issues.jboss.org/browse/DROOLS-2272
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Affects Versions: 7.5.0.Final
> Reporter: Michael Anstis
> Assignee: Michael Anstis
>
> Expression Editors have a row of controls to add row, column, change Hit Policy etc.
> These all need moving "inline" into the editor itself. -The content of the new context menu will be driven by the cell in the Expression grid that was (single) clicked. Double click continues to edit the cell.-
> *New requirements*
> * Context menu (single right-click) to provide the ability to cut/copy/paste/insert (row/column)/delete (row/column)/delete cell value
> * Double -Single- left-click to edit a cells content (this could be an {{TextBox}} or a {{ListBox}} or a more sophisticated editor).
> * Context menu entries are reflected in the state of the toolbar (menubar, whatever) in the workbench.
> This means the "Undefined Expression selector" ([DROOLS-2296|https://issues.jboss.org/browse/DROOLS-2296]), "Context Editor" ([DROOLS-2297|https://issues.jboss.org/browse/DROOLS-2297]) and "Relation Editor" ([DROOLS-2299|https://issues.jboss.org/browse/DROOLS-2299]) will need refactoring.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (DROOLS-2351) [DMN Editor] Move Editor controls inline. Sync menu bar with context menu
by Michael Anstis (JIRA)
Michael Anstis created DROOLS-2351:
--------------------------------------
Summary: [DMN Editor] Move Editor controls inline. Sync menu bar with context menu
Key: DROOLS-2351
URL: https://issues.jboss.org/browse/DROOLS-2351
Project: Drools
Issue Type: Enhancement
Components: DMN Editor
Reporter: Michael Anstis
Assignee: Michael Anstis
Following DROOLS-2272 the decision was made to have single right-click open a context menu "inline" in the editor (standard context menu stuff). However the actions on the context menu need also to be made available on the menu bar so Users can either use the menu bar or context menu.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Pedro Igor reassigned WFLY-9892:
--------------------------------
Assignee: Pedro Igor
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Assignee: Pedro Igor
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9892) Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-9892?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-9892:
----------------------------------
[~pcraveiro] It would be great if you could look at this one. Thanks!
> Upgrade org.apache.santuario.xmlsec to 2.1.1. caused regression in PicketLinkSTS
> --------------------------------------------------------------------------------
>
> Key: WFLY-9892
> URL: https://issues.jboss.org/browse/WFLY-9892
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.Beta1
> Reporter: Ondrej Lukas
> Priority: Blocker
> Attachments: ejb-security-picketlink.zip, ejb-test.jar, picketlink-sts.war, sts-config.properties
>
>
> When token from PicketLink STS is issued and signed then it is not able to be used for authentication through Remoting in WildFly 12 (i.e. it cannot be set as {{remote.connection.main.password}} property which can be used in PicketLink {{org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule}}). It seems it is caused by upgrade of org.apache.santuario.xmlsec to version 2.1.1. [1]. When WILDFLY11_HOME/modules/system/layers/base/org/apache/santuario/xmlsec/main/xmlsec-2.0.8.jar is placed to WildFly 12 modules then it works correctly.
> We report it as a blocker since it is regression - application which works correctly on WildFly 11 stops to work on WildFly 12 - users are not able to authenticate through Remoting with signed tokens from PicketLink STS correctly.
> Remoting fails due to following exception:
> {code}
> java.lang.IllegalArgumentException: ELY05131: Invalid ASCII control "0xA"
> at org.wildfly.security.sasl.util.StringPrep.forbidAsciiControl(StringPrep.java:117)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:295)
> at org.wildfly.security.sasl.util.StringPrep.encode(StringPrep.java:196)
> at org.wildfly.security.sasl.plain.PlainSaslClient.evaluateChallenge(PlainSaslClient.java:95)
> at org.wildfly.security.sasl.util.AbstractDelegatingSaslClient.evaluateChallenge(AbstractDelegatingSaslClient.java:54)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.lambda$evaluateChallenge$0(PrivilegedSaslClient.java:55)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.wildfly.security.sasl.util.PrivilegedSaslClient.evaluateChallenge(PrivilegedSaslClient.java:55)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.lambda$handleEvent$1(ClientConnectionOpenListener.java:460)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> It is caused by different formating value of SignatureValue in assertion. In WildFly 11 SignatureValue looks like:
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">nFVkKrXTyYEQ9cwc9OOgySYebEtwzw4alVYP0viXzvqZAUAKtAXEBAfDB8xIOms78twlDdq79MiSvk8OrOdf126Kw/IR8JRn1fYyZ5tsIRcNoTXMgGaTqhrn/HKlLqqqHhVHrJURunqkSzTTxylA2AEPhEDD5Y7hS0W2ZZCeSvuri+PRDSTrRnuedz0yQuHQu1mZ0gjoEFbHh4Wkkn5Ac1R4gmewmmzPud+ZE6Ux4YpeHzQ8rAvZ4bDk6j+eQIRsSxFTLo5RSA3FWN8+lUNV/CSRqBPXsK7QxOaTdBgF+4NXWeExrNJ9SeVFcf9yelvReAtR2JNZ6DUY8u45KtXmLw==</dsig:SignatureValue>
> {code}
> In WildFly 12 it looks like (there are end of lines):
> {code}
> <dsig:SignatureValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">cUNpFJIZlLYrBDZtQSTDrq2K6PbnAHyg2qbx/D5FuB4XMjdQ5oxQjkMejLyelnA7s4GFusoLhahl
> qlTOT8UrOyxrR4yYAmJ/e5s+f4gys926+tbiraT/3/wG8wM/Lvcjvk5Ap69zODuRYpypsWfA4jrI
> 7TTBXVPGy8g4KUdnFviUiTuFTc2Ghgxp53AmUuLis/THyP28jE7+28//q8bi/bQrFwHC6tWX67+N
> K1duFCOcQ6IPIKeVrePZz55Ivgl+WWdkF6uYCz5IdMzurhzmeQ3K8DAMIxz/MG67VWJIOnuGNWF7
> nmdye5zd9AFcRsr1XadvZJCbGNfuc89AL5inCg==</dsig:SignatureValue>
> {code}
> [1] https://github.com/wildfly/wildfly/commit/536de514829f2187abf1126c8916a04...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9706) Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-9706?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-9706:
-----------------------------------
WFCORE-3651 is preventing backwards compatibility.
> Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9706
> URL: https://issues.jboss.org/browse/WFLY-9706
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Jeff Mesnil
> Priority: Blocker
>
> This Jira is reaction to WFLY-9433.
> The WFLY-9433 makes validator rules more strict for some attributes in messaging subsystem. Although there is no reason to use these values (which are newly considered as invalid), it was possible to configure them and they worked with Wildfly 11 and previous releases.
> As it is proposed in JBEAP-14110, this change should be done in 2 steps:
> * only WARN the user if the parameter is not valid (a negative value other than -1)
> * in next release, reject the parameter
> I am setting priority as Blocker, because this fix must be included in Wildfly 12 release. It makes no sense to do it later.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9910) CustomUndertowFilterTestCase fails to reload server if node0!=localhost
by Petr Kremensky (JIRA)
Petr Kremensky created WFLY-9910:
------------------------------------
Summary: CustomUndertowFilterTestCase fails to reload server if node0!=localhost
Key: WFLY-9910
URL: https://issues.jboss.org/browse/WFLY-9910
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 12.0.0.Beta1
Reporter: Petr Kremensky
Assignee: Petr Kremensky
org.jboss.as.test.manualmode.undertow.CustomUndertowFilterTestCase stuck on server reload
{noformat}
ServerReload.executeReloadAndWaitForCompletion(controllerClient);
{noformat}
if node0!=localhost. Use
{noformat}
serverController.reload();
{noformat}
instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3651) ParameterCorrector are not taken into account when XML is parsed
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFCORE-3651:
-----------------------------------
Summary: ParameterCorrector are not taken into account when XML is parsed
Key: WFCORE-3651
URL: https://issues.jboss.org/browse/WFCORE-3651
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 4.0.0.Beta2
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 4.0.0.CR1
The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
This works fine when DMR operations are executed against the server.
However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
However this duplicates code that is already done in AttributeDefinition.validateAndSet.
We could handle all this logic (correction/validation) only when the DMP operations are executed.
However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3651) ParameterCorrector are not taken into account by XML parser
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3651?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3651:
--------------------------------
Summary: ParameterCorrector are not taken into account by XML parser (was: ParameterCorrector are not taken into account when XML is parsed)
> ParameterCorrector are not taken into account by XML parser
> -----------------------------------------------------------
>
> Key: WFCORE-3651
> URL: https://issues.jboss.org/browse/WFCORE-3651
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 4.0.0.Beta2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 4.0.0.CR1
>
>
> The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
> This works fine when DMR operations are executed against the server.
> However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
> I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
> If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
> Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
> The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
> However this duplicates code that is already done in AttributeDefinition.validateAndSet.
> We could handle all this logic (correction/validation) only when the DMP operations are executed.
> However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
> So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFCORE-3651) ParameterCorrector are not taken into account by XML parser
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3651?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3651:
--------------------------------
Description:
The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
This works fine when DMR operations are executed against the server.
However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
However this duplicates code that is already done in AttributeDefinition.validateAndSet.
We could handle all this logic (correction/validation) only when the DMR operations are executed.
However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
was:
The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
This works fine when DMR operations are executed against the server.
However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
However this duplicates code that is already done in AttributeDefinition.validateAndSet.
We could handle all this logic (correction/validation) only when the DMP operations are executed.
However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
> ParameterCorrector are not taken into account by XML parser
> -----------------------------------------------------------
>
> Key: WFCORE-3651
> URL: https://issues.jboss.org/browse/WFCORE-3651
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 4.0.0.Beta2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Fix For: 4.0.0.CR1
>
>
> The ParameterCorrector of an AttributeDefinition must attempt to correct the value before the value is validated against the AttributeDefinition's ParameterValidator.
> This works fine when DMR operations are executed against the server.
> However, this fails when XML is parsed as the XML parser is validating the value without correcting it first.
> I encounter this issue in WFLY-9706 when the validator constrains to use only -1 instead of any negative value.
> If I had a ParameterCorrect that correct any negative values (e.g. -3) to -1, the XML parser fails because the value (-3) is not valid (must be -1).
> Using :write-attribute works fine as the ParameterCorrect will correct -3 to -1 before it is validated.
> The simple short term fix is to call the ParameterCorrect when the XML parser read the attribute before it validates its value.
> However this duplicates code that is already done in AttributeDefinition.validateAndSet.
> We could handle all this logic (correction/validation) only when the DMR operations are executed.
> However doing so would make it impossible to report informative XML errors as the user would have to find how the faulty DMR op map to the XML file he provided.
> So keeping this logic of correction/validation when XML is parsed is useful for error reporting but it should delegate to some methods of AttributeDefinition instead of duplicating the code (and missing some cases such as parameter correction)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months