February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4337) Bump logging schema and model versions

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-4337?page=com.atlassian.jira.plugi... ] James Perkins moved WFLY-11743 to WFCORE-4337: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-4337 (was: WFLY-11743) Component/s: Logging (was: Logging) > Bump logging schema and model versions > -------------------------------------- > > Key: WFCORE-4337 > URL: https://issues.jboss.org/browse/WFCORE-4337 > Project: WildFly Core > Issue Type: Task > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > > The logging subsystem schema needs to be bumped from 6.0 to 7.0. The logging subsystem model version needs to be bumped from 7.0.0 to 8.0.0. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3661) Executable model cannot parse enum in a constraint with from

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3661?page=com.atlassian.jira.plugi... ] Mario Fusco reassigned DROOLS-3661: ----------------------------------- Assignee: Mario Fusco (was: Tibor Zimányi) > Executable model cannot parse enum in a constraint with from > ------------------------------------------------------------ > > Key: DROOLS-3661 > URL: https://issues.jboss.org/browse/DROOLS-3661 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.17.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Priority: Major > > Having a following test case [1], executable model fails with a following stacktrace [2]. PR with a reproducer can be found here [3]. > [1] https://gist.github.com/baldimir/e5a6af0221f2f6784802be7529b5e4f7 > [2] https://gist.github.com/baldimir/8a57c0dbd1dc5f0482c44339f8eba354 > [3] https://github.com/kiegroup/drools/pull/2259 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3661) Executable model cannot parse enum in a constraint with from

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3661?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-3661: -------------------------------- Sprint: 2019 Week 08-10 > Executable model cannot parse enum in a constraint with from > ------------------------------------------------------------ > > Key: DROOLS-3661 > URL: https://issues.jboss.org/browse/DROOLS-3661 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.17.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Priority: Major > > Having a following test case [1], executable model fails with a following stacktrace [2]. PR with a reproducer can be found here [3]. > [1] https://gist.github.com/baldimir/e5a6af0221f2f6784802be7529b5e4f7 > [2] https://gist.github.com/baldimir/8a57c0dbd1dc5f0482c44339f8eba354 > [3] https://github.com/kiegroup/drools/pull/2259 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Darran Lofthouse edited comment on WFLY-11604 at 2/18/19 1:49 PM: ------------------------------------------------------------------ I see the difference now and believe this is the intended behaviour. At the moment just looking at testNonAnonymousPrincipalInjected() we have two calls: - 1 - CallerWithIdentity->BeanWithInjectedPrincipal 2 - CallerWithIdentity->BeanWithPrincipalFromEJBContext The bean CallerWithIdentity is configured with a run-as-principal of 'non-anonymous'. This run as principal affects outbound calls from this bean so when we call a different EJB the identity is switched. In scenario #2 the call is to a different EJB, this means the call passes through security interceptors which identify any outbound principal and make use of it for the next stage in the call. This is expected and in the test the expected value is being returned. In scenario #1 however the call does not pass to another EJB, instead it passes directly to an injected CDI bean. As this bean is directly injected it is running using the SecurityContext of the CallerWithIdentity bean so it is correct that this is returning 'anonymous' instead of 'non-anonymous'. If I change the call to: - 3 - CallerWithIdentity->BeanWithPrincipalFromEJBContext -> BeanWithInjectedPrincipal Now the call leaves 'CallerWithIdentity' and enters a second EJB so the run-as-principal is used, the injected CDI bean is now using the security context of the second bean so returns 'non-anonymous'. This does however leave the question once WildFly Elytron is activated regarding why the EJBContext does not report the run as principal when the call reaches the second bean, I suspect this may have been a decision during implementation as these run as scenarios were discussed quite heavily but it is purely an EJB container issue and not a CDI issue. was (Author: dlofthouse): I see the difference now and believe this is the intended behaviour. At the moment just looking at testNonAnonymousPrincipalInjected() we have two calls: - 1 - CallerWithIdentity->BeanWithInjectedPrincipal 2 - CallerWithIdentity->BeanWithPrincipalFromEJBContext The bean CallerWithIdentity is configured with a run-as-principal of 'non-anonymous'. This run as principal affects outbound calls from this bean so when we call a different EJB the identity is switched. In scenario #2 the call is to a different EJB, this means the call passes through security interceptors which identify any outbound principal and make use of it for the next stage in the call. This is expected and in the test the expected value is being returned. In scenario #1 however the call does not pass to another EJB, instead it passes directly to an injected CDI bean. As this bean is directly injected it is running using the SecurityContext of the CallerWithIdentity bean so it is correct that this is returning 'anonymous' instead of 'non-anonymous'. If I change the call to: - 3 - CallerWithIdentity->BeanWithPrincipalFromEJBContext -> BeanWithInjectedPrincipal Now the call leaves 'CallerWithIdentity' and enters a second EJB so the run-as-principal is used, the injected CDI bean is now using the security context of the second bean so returns 'non-anonymous'. This does however leave the question regarding why the EJBContext does not report the run as principal when the call reaches the second bean, I suspect this may have been a decision during implementation as these run as scenarios were discussed quite heavily but it is purely an EJB container issue and not a CDI issue. > Non-anonymous principal is not propagated from EJB context to CDI bean > ---------------------------------------------------------------------- > > Key: WFLY-11604 > URL: https://issues.jboss.org/browse/WFLY-11604 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: Nikoleta Žiaková > Assignee: Darran Lofthouse > Priority: Critical > > This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal. > However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...]. > The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11604) Non-anonymous principal is not propagated from EJB context to CDI bean

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-11604?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFLY-11604: ----------------------------------------- I see the difference now and believe this is the intended behaviour. At the moment just looking at testNonAnonymousPrincipalInjected() we have two calls: - 1 - CallerWithIdentity->BeanWithInjectedPrincipal 2 - CallerWithIdentity->BeanWithPrincipalFromEJBContext The bean CallerWithIdentity is configured with a run-as-principal of 'non-anonymous'. This run as principal affects outbound calls from this bean so when we call a different EJB the identity is switched. In scenario #2 the call is to a different EJB, this means the call passes through security interceptors which identify any outbound principal and make use of it for the next stage in the call. This is expected and in the test the expected value is being returned. In scenario #1 however the call does not pass to another EJB, instead it passes directly to an injected CDI bean. As this bean is directly injected it is running using the SecurityContext of the CallerWithIdentity bean so it is correct that this is returning 'anonymous' instead of 'non-anonymous'. If I change the call to: - 3 - CallerWithIdentity->BeanWithPrincipalFromEJBContext -> BeanWithInjectedPrincipal Now the call leaves 'CallerWithIdentity' and enters a second EJB so the run-as-principal is used, the injected CDI bean is now using the security context of the second bean so returns 'non-anonymous'. This does however leave the question regarding why the EJBContext does not report the run as principal when the call reaches the second bean, I suspect this may have been a decision during implementation as these run as scenarios were discussed quite heavily but it is purely an EJB container issue and not a CDI issue. > Non-anonymous principal is not propagated from EJB context to CDI bean > ---------------------------------------------------------------------- > > Key: WFLY-11604 > URL: https://issues.jboss.org/browse/WFLY-11604 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Security > Affects Versions: 14.0.1.Final, 15.0.1.Final > Reporter: Nikoleta Žiaková > Assignee: Darran Lofthouse > Priority: Critical > > This is a follow-up on WFLY-11587 which only dealt with being able to inject the principal. > However, during testing I have tried a scenario when the caller principal was not anonymous (run-as-principal setting in jboss-ejb3.xml). See the test case in this [commit|https://github.com/nziakova/wildfly/commit/9ae586ad0159e6399f65103...]. > The principal is not propagated from the EJB context. The result is that injected principal in the CDI bean is always anonymous, although {{ctx.getCallerPrincipal()}} in the EJB returns correct principal. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11743) Bump logging schema and model versions

by James Perkins (Jira)

James Perkins created WFLY-11743: ------------------------------------ Summary: Bump logging schema and model versions Key: WFLY-11743 URL: https://issues.jboss.org/browse/WFLY-11743 Project: WildFly Issue Type: Task Components: Logging Reporter: James Perkins Assignee: James Perkins The logging subsystem schema needs to be bumped from 6.0 to 7.0. The logging subsystem model version needs to be bumped from 7.0.0 to 8.0.0. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3670) Function now doesn't work with between expression

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3670?page=com.atlassian.jira.plugi... ] Matteo Mortari commented on DROOLS-3670: ---------------------------------------- There is an edge case for the {{between}} operator which needs alignment following DMNv1.2 updates, the linked reproducer exhibit the issue for the case of comparing datetime(withTz) and without > Function now doesn't work with between expression > ------------------------------------------------- > > Key: DROOLS-3670 > URL: https://issues.jboss.org/browse/DROOLS-3670 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.18.0.Final > Reporter: Jozef Marko > Assignee: Matteo Mortari > Priority: Major > > Please see the linked [PR|https://github.com/kiegroup/drools/pull/2261/files]. There is created test that evalutes expression {{now() between dateTimeA and dateTimeB}}. The test passes arguments to evaluate the decision as {{false}}, however the decision is returning {{null}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3670) DMN `between` FEEL operator alignments

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3670?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-3670: ----------------------------------- Summary: DMN `between` FEEL operator alignments (was: Function now doesn't work with between expression) > DMN `between` FEEL operator alignments > -------------------------------------- > > Key: DROOLS-3670 > URL: https://issues.jboss.org/browse/DROOLS-3670 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.18.0.Final > Reporter: Jozef Marko > Assignee: Matteo Mortari > Priority: Major > > Please see the linked [PR|https://github.com/kiegroup/drools/pull/2261/files]. There is created test that evalutes expression {{now() between dateTimeA and dateTimeB}}. The test passes arguments to evaluate the decision as {{false}}, however the decision is returning {{null}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3670) Function now doesn't work with between expression

by Matteo Mortari (Jira)

[ https://issues.jboss.org/browse/DROOLS-3670?page=com.atlassian.jira.plugi... ] Matteo Mortari reassigned DROOLS-3670: -------------------------------------- Assignee: Matteo Mortari (was: Edson Tirelli) > Function now doesn't work with between expression > ------------------------------------------------- > > Key: DROOLS-3670 > URL: https://issues.jboss.org/browse/DROOLS-3670 > Project: Drools > Issue Type: Bug > Components: dmn engine > Affects Versions: 7.18.0.Final > Reporter: Jozef Marko > Assignee: Matteo Mortari > Priority: Major > > Please see the linked [PR|https://github.com/kiegroup/drools/pull/2261/files]. There is created test that evalutes expression {{now() between dateTimeA and dateTimeB}}. The test passes arguments to evaluate the decision as {{false}}, however the decision is returning {{null}}. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11738) Upgrade JGroups to 4.0.18.Final

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11738?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11738: ---------------------------------- Description: No changelog on the Jira (https://issues.jboss.org/projects/JGRP/versions/12340553). Github changelog https://github.com/belaban/JGroups/commits/JGroups-4.0.18.Final was: No changelog on the Jira (https://issues.jboss.org/projects/JGRP/versions/12340553). > Upgrade JGroups to 4.0.18.Final > ------------------------------- > > Key: WFLY-11738 > URL: https://issues.jboss.org/browse/WFLY-11738 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 16.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > > No changelog on the Jira (https://issues.jboss.org/projects/JGRP/versions/12340553). > Github changelog https://github.com/belaban/JGroups/commits/JGroups-4.0.18.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2019