June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-5399) The collect/accumulate function with expired event is sensible to the order of inserted events

by Gary Hu (Jira)

[ https://issues.redhat.com/browse/DROOLS-5399?page=com.atlassian.jira.plug... ] Gary Hu closed DROOLS-5399. --------------------------- Resolution: Done > The collect/accumulate function with expired event is sensible to the order of inserted events > ---------------------------------------------------------------------------------------------- > > Key: DROOLS-5399 > URL: https://issues.redhat.com/browse/DROOLS-5399 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.38.0.Final > Reporter: Gary Hu > Assignee: Mario Fusco > Priority: Major > > If the function collect/accumulate is used in the beta node(left constraint) with expired event, it's sensible to the order of events being inserted, which should not. This issue didn't happen in bpms 6.4. It occurs in rhdm 7.x. > For example: > "import " + DummyEvent.class.getCanonicalName() + "\n" + > "import " + OtherEvent.class.getCanonicalName() + "\n" + > "import " + HashSet.class.getCanonicalName() + "\n" + > "declare DummyEvent " + > "@role( event ) " + > "@timestamp( eventTimestamp )\n" + > "@expires(0ms)" + > "end\n" + > "declare OtherEvent " + > "@role( event ) " + > "@timestamp( eventTimestamp )" + > "@expires(2d)" + > "end\n" + > "rule R0 when\n" + > " $d: OtherEvent() \n" + > " $r: HashSet ( size >= 2 ) from collect (DummyEvent())\n" + > "then\n" + > " System.out.println(\"R0 Fired\");" + > "end"; > If you insert events like: > ksession.insert( other); > ksession.insert( dummyEvent0 ); > ksession.insert( dummyEvent1); > The rule gets fired. But if you inserts the events like: > ksession.insert( dummyEvent0 ); > ksession.insert( other); > ksession.insert( dummyEvent1); > The rule doesn't get fired. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5399) The collect/accumulate function with expired event is sensible to the order of inserted events

by Gary Hu (Jira)

Gary Hu created DROOLS-5399: ------------------------------- Summary: The collect/accumulate function with expired event is sensible to the order of inserted events Key: DROOLS-5399 URL: https://issues.redhat.com/browse/DROOLS-5399 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.38.0.Final Reporter: Gary Hu Assignee: Mario Fusco If the function collect/accumulate is used in the beta node(left constraint) with expired event, it's sensible to the order of events being inserted, which should not. This issue didn't happen in bpms 6.4. It occurs in rhdm 7.x. For example: "import " + DummyEvent.class.getCanonicalName() + "\n" + "import " + OtherEvent.class.getCanonicalName() + "\n" + "import " + HashSet.class.getCanonicalName() + "\n" + "declare DummyEvent " + "@role( event ) " + "@timestamp( eventTimestamp )\n" + "@expires(0ms)" + "end\n" + "declare OtherEvent " + "@role( event ) " + "@timestamp( eventTimestamp )" + "@expires(2d)" + "end\n" + "rule R0 when\n" + " $d: OtherEvent() \n" + " $r: HashSet ( size >= 2 ) from collect (DummyEvent())\n" + "then\n" + " System.out.println(\"R0 Fired\");" + "end"; If you insert events like: ksession.insert( other); ksession.insert( dummyEvent0 ); ksession.insert( dummyEvent1); The rule gets fired. But if you inserts the events like: ksession.insert( dummyEvent0 ); ksession.insert( other); ksession.insert( dummyEvent1); The rule doesn't get fired. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1978) (7.3.z) Update error message returned by AcmeClientSpi#getLocation

by Ilia Vassilev (Jira)

Ilia Vassilev created ELY-1978: ---------------------------------- Summary: (7.3.z) Update error message returned by AcmeClientSpi#getLocation Key: ELY-1978 URL: https://issues.redhat.com/browse/ELY-1978 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Reporter: Ilia Vassilev Assignee: Sonia Zaldana Fix For: 1.12.0.Final The {{AcmeClientSpi#getLocation}} method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the {{AcmeClientSpi#getLocation}} method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5398) The collect/accumulate function with expired event is sensible to the order of inserted events

by Gary Hu (Jira)

Gary Hu created DROOLS-5398: ------------------------------- Summary: The collect/accumulate function with expired event is sensible to the order of inserted events Key: DROOLS-5398 URL: https://issues.redhat.com/browse/DROOLS-5398 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.38.0.Final Reporter: Gary Hu Assignee: Mario Fusco If the function collect/accumulate is used in the beta node(left constraint) with expired event, it's sensible to the order of events being inserted, which should not. This issue didn't happen in bpms 6.4. It occurs in rhdm 7.x. For example: "import " + DummyEvent.class.getCanonicalName() + "\n" + "import " + OtherEvent.class.getCanonicalName() + "\n" + "import " + HashSet.class.getCanonicalName() + "\n" + "declare DummyEvent " + "@role( event ) " + "@timestamp( eventTimestamp )\n" + "@expires(0ms)" + "end\n" + "declare OtherEvent " + "@role( event ) " + "@timestamp( eventTimestamp )" + "@expires(2d)" + "end\n" + "rule R0 when\n" + " $d: OtherEvent() \n" + " $r: HashSet ( size >= 2 ) from collect (DummyEvent())\n" + "then\n" + " System.out.println(\"R0 Fired\");" + "end"; If you insert events like: ksession.insert( other); ksession.insert( dummyEvent0 ); ksession.insert( dummyEvent1); The rule gets fired. But if you inserts the events like: ksession.insert( dummyEvent0 ); ksession.insert( other); ksession.insert( dummyEvent1); The rule doesn't get fired. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13551) Upgrade wildfly-naming-client to 1.0.13.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13551?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13551: ------------------------------------ Fix Version/s: 20.0.0.Final > Upgrade wildfly-naming-client to 1.0.13.Final > --------------------------------------------- > > Key: WFLY-13551 > URL: https://issues.redhat.com/browse/WFLY-13551 > Project: WildFly > Issue Type: Component Upgrade > Components: Naming > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Final > > > Pick up https://issues.redhat.com/browse/WFNC-57 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13522) Upgrade jboss-ejb-client to 4.0.33.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13522?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13522: ------------------------------------ Fix Version/s: 20.0.0.Final > Upgrade jboss-ejb-client to 4.0.33.Final > ---------------------------------------- > > Key: WFLY-13522 > URL: https://issues.redhat.com/browse/WFLY-13522 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Ilia Vassilev > Assignee: Tomasz Adamski > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13550) Upgrade WildFly Core 12.0.0.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13550?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-13550: ------------------------------- Priority: Blocker (was: Major) > Upgrade WildFly Core 12.0.0.Final > --------------------------------- > > Key: WFLY-13550 > URL: https://issues.redhat.com/browse/WFLY-13550 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Blocker > Fix For: 20.0.0.Final > > > Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Final > Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta4...12.0.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13551) Upgrade wildfly-naming-client to 1.0.13.Final

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13551: --------------------------------------- Summary: Upgrade wildfly-naming-client to 1.0.13.Final Key: WFLY-13551 URL: https://issues.redhat.com/browse/WFLY-13551 Project: WildFly Issue Type: Component Upgrade Components: Naming Reporter: Brian Stansberry Assignee: Brian Stansberry Pick up https://issues.redhat.com/browse/WFNC-57 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13550) Upgrade WildFly Core 12.0.0.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFLY-13550?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFLY-13550: ------------------------------- Description: Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Final Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta4...12.0.0.Final was: Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Beta4 Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta3...12.0.0.Beta4 > Upgrade WildFly Core 12.0.0.Final > --------------------------------- > > Key: WFLY-13550 > URL: https://issues.redhat.com/browse/WFLY-13550 > Project: WildFly > Issue Type: Component Upgrade > Components: Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Priority: Major > Fix For: 20.0.0.Final > > > Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Final > Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta4...12.0.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13550) Upgrade WildFly Core 12.0.0.Final

by Jeff Mesnil (Jira)

Jeff Mesnil created WFLY-13550: ---------------------------------- Summary: Upgrade WildFly Core 12.0.0.Final Key: WFLY-13550 URL: https://issues.redhat.com/browse/WFLY-13550 Project: WildFly Issue Type: Component Upgrade Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 20.0.0.Final Tag + Release Notes: https://github.com/wildfly/wildfly-core/releases/tag/12.0.0.Beta4 Diff to previous integrated version: https://github.com/wildfly/wildfly-core/compare/12.0.0.Beta3...12.0.0.Beta4 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 June 2020