[JBoss JIRA] (WFCORE-2740) Recursive read-resource should not fail if an expected address type disappears in the middle of execution
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2740?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2740:
-------------------------------------
Fix Version/s: (was: 4.0.0.Alpha1)
> Recursive read-resource should not fail if an expected address type disappears in the middle of execution
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2740
> URL: https://issues.jboss.org/browse/WFCORE-2740
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> The ManagementResourceRegistration tree is not cloned upon modification the way Resource tree is. That means read ops executing concurrently with ops that modify the MRR tree can have the tree change underneath them.
> This can affect recursive read-resource ops, as they calculate possible child addresses and then later they process those addresses, failing if an MRR is missing. A failure only makes sense if the user did something wrong or, perhaps, if it's clear that the code is broken. But here there's a perfectly valid reason for the MRR to be missing, so there should be no failure.
> Not an urgent thing; I saw this quite a while ago when investigating a different issue and quickly worked up a fix which has now been sitting around gathering dust.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2547) Revisit the meaning of aggregate-principal-transformer
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2547?page=com.atlassian.jira.plugi... ]
Jan Kalina reassigned WFCORE-2547:
----------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Revisit the meaning of aggregate-principal-transformer
> ------------------------------------------------------
>
> Key: WFCORE-2547
> URL: https://issues.jboss.org/browse/WFCORE-2547
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: principal-transformer
>
> Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See:
> * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that?
> * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case?
> * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used?
> This issue is reported based on previous discussion with engineering.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2547) Revisit the meaning of aggregate-principal-transformer
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2547?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-2547:
-------------------------------
Labels: principal-transformer (was: )
> Revisit the meaning of aggregate-principal-transformer
> ------------------------------------------------------
>
> Key: WFCORE-2547
> URL: https://issues.jboss.org/browse/WFCORE-2547
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: principal-transformer
>
> Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See:
> * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that?
> * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case?
> * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used?
> This issue is reported based on previous discussion with engineering.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2547) Revisit the meaning of aggregate-principal-transformer
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2547?page=com.atlassian.jira.plugi... ]
Jan Kalina updated WFCORE-2547:
-------------------------------
Priority: Blocker (was: Critical)
> Revisit the meaning of aggregate-principal-transformer
> ------------------------------------------------------
>
> Key: WFCORE-2547
> URL: https://issues.jboss.org/browse/WFCORE-2547
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: principal-transformer
>
> Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See:
> * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that?
> * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case?
> * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used?
> This issue is reported based on previous discussion with engineering.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ]
Jan Kalina moved JBEAP-10637 to ELY-1115:
-----------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-1115 (was: JBEAP-10637)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Utils
(was: Security)
Affects Version/s: 1.1.0.Beta38
(was: 7.1.0.DR14)
> Revisit the meaning of aggregate-principal-transformer
> ------------------------------------------------------
>
> Key: ELY-1115
> URL: https://issues.jboss.org/browse/ELY-1115
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Utils
> Affects Versions: 1.1.0.Beta38
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: management-model, principal-transformer
>
> Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See:
> * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that?
> * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case?
> * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used?
> This issue is reported based on previous discussion with engineering.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1115:
----------------------------
Labels: management-model principal-transformer (was: KK-DR18 eap7.1-rfe-failure management-model principal-transformer)
> Revisit the meaning of aggregate-principal-transformer
> ------------------------------------------------------
>
> Key: ELY-1115
> URL: https://issues.jboss.org/browse/ELY-1115
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Utils
> Affects Versions: 1.1.0.Beta38
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: management-model, principal-transformer
>
> Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See:
> * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that?
> * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case?
> * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used?
> This issue is reported based on previous discussion with engineering.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-2740) Recursive read-resource should not fail if an expected address type disappears in the middle of execution
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2740:
----------------------------------------
Summary: Recursive read-resource should not fail if an expected address type disappears in the middle of execution
Key: WFCORE-2740
URL: https://issues.jboss.org/browse/WFCORE-2740
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
Fix For: 4.0.0.Alpha1
The ManagementResourceRegistration tree is not cloned upon modification the way Resource tree is. That means read ops executing concurrently with ops that modify the MRR tree can have the tree change underneath them.
This can affect recursive read-resource ops, as they calculate possible child addresses and then later they process those addresses, failing if an MRR is missing. A failure only makes sense if the user did something wrong or, perhaps, if it's clear that the code is broken. But here there's a perfectly valid reason for the MRR to be missing, so there should be no failure.
Not an urgent thing; I saw this quite a while ago when investigating a different issue and quickly worked up a fix which has now been sitting around gathering dust.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (DROOLS-1541) newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
by Daniel B. (JIRA)
Daniel B. created DROOLS-1541:
---------------------------------
Summary: newInsert.outIdentifier/getValue.identifier don't refer via fact handle (as per doc.), get only original, not replacement, fact object instances
Key: DROOLS-1541
URL: https://issues.jboss.org/browse/DROOLS-1541
Project: Drools
Issue Type: Bug
Affects Versions: 6.5.0.Final, 6.3.0.Final
Reporter: Daniel B.
Assignee: Edson Tirelli
The identifier passed to the {{KieCommands.newInsert}} method's {{outIdentifier}} parameter and to the {{ExecutionResults.getValue}} method's {{identifier}} parameter doesn't actually refer to the fact object _via the fact handle_ as described in the documentation of {{InsertObjectCommand}}).
The documentation says:
{quote}
11.2.2. InsertObjectCommand
...
outIdentifier Id to identify the FactHandle created in the object insertion and added to the execution results
{quote}
Although the Drools code in method {{InsertObjectCommand.execute}} does map the given identifier both to the original object and to the fact handle, the code in method {{ExecutionResultImpl.getValue}} retrieves the _original_ object instead of retrieving the object _currently associated with the fact handle_.
This means that if the original fact object instance is replaced with a different instance (e.g., with {{update(kcontext.getKieRuntime().getFactHandle($oldObj), newObj);}} in the rules), then {{ExecutionResults.getValue}} will return the _original_ fact object, not the _current_ value of the fact object (the object instance currently associated with the fact handle created in the {{newInsert}} call).
That in turn means that immutable fact object instances cannot be used with {{ExecutionResults.getValue}}.
(It's not 100% clear that it's the code that is wrong (relative to the documentation) rather than it being documentation that's wrong (relative to the code). However, the behavior described by the documentation seems more useful than the behavior exhibited by the code.)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months