May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] GaoShengwei GaoShengwei updated DROOLS-1590: -------------------------------------------- Description: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. was: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] GaoShengwei GaoShengwei updated DROOLS-1590: -------------------------------------------- Description: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output sequence was extactly same with screenshot. was: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output sequence was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] GaoShengwei GaoShengwei updated DROOLS-1590: -------------------------------------------- Description: I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output is different from the screenshot. But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] GaoShengwei GaoShengwei updated DROOLS-1590: -------------------------------------------- Attachment: BaiduHi_2017-5-31_18-1-18.png BaiduHi_2017-5-31_18-2-54.png > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by GaoShengwei GaoShengwei (JIRA)

GaoShengwei GaoShengwei created DROOLS-1590: ----------------------------------------------- Summary: The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final Key: DROOLS-1590 URL: https://issues.jboss.org/browse/DROOLS-1590 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.5.0.Final Reporter: GaoShengwei GaoShengwei Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ] Jan Kalina updated ELY-1151: ---------------------------- Fix Version/s: (was: 1.1.0.Beta44) > Empty authorization name for Digest mechanism causes authentication fail > ------------------------------------------------------------------------ > > Key: ELY-1151 > URL: https://issues.jboss.org/browse/ELY-1151 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta38 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > > SASL specification says about Authorization Identity String [1]: > {quote} > If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.* > {quote} > In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string. > It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name. > It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail. > The same issue can occurs for every supported SASL mechanism. In needs to be revisited. > We request blocker flag since current behavior violates SASL specification. > [1] https://tools.ietf.org/html/rfc4422#section-3.4.1 > [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1151: --------------------------------- PR 810: client side NameCallback PR 848: server side AuthorizationCallback > Empty authorization name for Digest mechanism causes authentication fail > ------------------------------------------------------------------------ > > Key: ELY-1151 > URL: https://issues.jboss.org/browse/ELY-1151 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta38 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Fix For: 1.1.0.Beta44 > > > SASL specification says about Authorization Identity String [1]: > {quote} > If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.* > {quote} > In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string. > It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name. > It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail. > The same issue can occurs for every supported SASL mechanism. In needs to be revisited. > We request blocker flag since current behavior violates SASL specification. > [1] https://tools.ietf.org/html/rfc4422#section-3.4.1 > [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-502) ClasspathKieProject fails vfs: try to unzip exploded jar

by Nicolas-Xavier Vanderlinden (JIRA)

[ https://issues.jboss.org/browse/DROOLS-502?page=com.atlassian.jira.plugin... ] Nicolas-Xavier Vanderlinden commented on DROOLS-502: ---------------------------------------------------- Bug fixed in the 7.0.0 version (DROOLS-1065). You can close this ticket. > ClasspathKieProject fails vfs: try to unzip exploded jar > -------------------------------------------------------- > > Key: DROOLS-502 > URL: https://issues.jboss.org/browse/DROOLS-502 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Beta4, 6.2.0.CR3 > Reporter: Nicolas-Xavier Vanderlinden > Assignee: Mark Proctor > > Drools is not able to load kmodule.xml from an exploded jar inside an exploded ear. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8459) @TransactionAttribute should not be inherited per EJB 3.2 spec

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8459?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-8459: ----------------------------------------------- Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1442955|https://bugzilla.redhat.com/show_bug.cgi?id=1442955] from POST to MODIFIED > @TransactionAttribute should not be inherited per EJB 3.2 spec > --------------------------------------------------------------- > > Key: WFLY-8459 > URL: https://issues.jboss.org/browse/WFLY-8459 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: JBoss EA P7.0.x > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 11.0.0.Beta1 > > > It appears that JBoss EAP behaves as the *@TransactionAttribute* attribute was inherited. > For example if I have a bean A that > {noformat} > @Stateless > @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) > public class ABean extends Base{ > > public void foo(){ . . .} > } > {noformat} > and a supper class > {noformat} > @TransactionAttribute(TransactionAttributeType.SUPPORTS) > public class Base { > > @TransactionAttribute(TransactionAttributeType.NEVER) > public void foo(){ . . } > public void bar(){ . . .} > } > {noformat} > and if I call each method > {noformat} > beanA.bar(); > beanA.foo(); > {noformat} > I would expect to see *bar()* without an active transaction and *foo()* with an active transaction > but what I see is that both method have no active transaction. This seems like spec violation since the *@TransactionAttribute* are not supposed to be inherited. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7949) Missing a simple way to enable Elytron

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7949?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7949: ---------------------------------- Adding feature-pack/src/main/resources/content/docs/examples/enable-elytron.cli https://github.com/wildfly/wildfly/pull/10100 > Missing a simple way to enable Elytron > -------------------------------------- > > Key: WFLY-7949 > URL: https://issues.jboss.org/browse/WFLY-7949 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Critical > Labels: user_experience > Fix For: 11.0.0.Beta1 > > > There should be a simple way (e.g. a CLI script provided with AS distribution) which would enable the Elytron in subsystems. As the {{standalone-elytron.xml}} profile was removed now, users don't have a one-step way to use the Elytron. > I've put some CLI commands together for my testing, but I doubt this is a complete solution: > http://javlog.cacek.cz/2017/01/enable-elytron-in-wildfly.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 May 2017