January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-694) accumulate with sliding window and other LHS condition

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-694?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-694: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > accumulate with sliding window and other LHS condition > ------------------------------------------------------ > > Key: DROOLS-694 > URL: https://issues.jboss.org/browse/DROOLS-694 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR4 > Environment: fail with PHREAK, work correctly as expected with RETEOO > Reporter: Matteo Mortari > Assignee: Mario Fusco > Attachments: 20150121.accumulate-window-counter.zip > > > With reference to attached reproducer. > Assuming the following KB, where to goal is to keep a {{Counter}} fact for the amount of {{Measurement}} events received in the last hour. > {code:java} > declare Measurement > @role(event) > end > rule "Init Counter last 1h" > agenda-group "USERSPACE" > salience 1 > no-loop > when > not Counter( name == "Counter last 1h" ) > then > Counter c = new Counter("Counter last 1h", 0); > insert(c); > System.out.println("RHS Init Counter last 1h " + c); > end > rule "Update Counter last 1h" > agenda-group "USERSPACE" > no-loop > when > accumulate( $token : Measurement() over window:time( 1h ) ; > $val : count($token) > ) > $cv1 : Counter( name == "Counter last 1h", value != $val.doubleValue() ) > then > int count = $val.intValue(); > $cv1.setValue(count); > update($cv1); > System.out.println("RHS Update Counter last 1h : "+$cv1); > end > {code} > The following Unit test shall have the effect in the end to obtain value 2.0 in the {{Counter}} object, as I've inserted 2 {{MEasurement}} within the last hour and within two minutes > {code:java} > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "220")); > fire(session); > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "221")); > fire(session); > LOG.info("Final checks"); > Counter counter = (Counter) session.getObjects(counterFilter).iterator().next(); // I'm taking a shortcut as for this reproducer I know there is only 1 Counter in WM > assertEquals("I've inserted 2 Measurement within the hour ", 2, counter.getValue(), 0); > {code} > However this works only with ReteOO and the test FAILS with Phreak. > Can you kindly advise, please? > Thank you > MM -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-694) accumulate with sliding window and other LHS condition

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-694?page=com.atlassian.jira.plugin... ] Mario Fusco commented on DROOLS-694: ------------------------------------ Ciao Matteo, I just started investigating this test case and the problem seems to be caused by the no-loop in the 2nd rule. You really don't need it and removing the no-loop fixes your test cases. Moreover the problem seems not related with the use of a sliding window of with the stream mode at all. I can reproduce the same issue even removing them. I'm now trying to develop a simple reproducer with only the strictly necessary ingredients and figure out what's going wrong. In the meanwhile I hope this hint could be of some help for you. > accumulate with sliding window and other LHS condition > ------------------------------------------------------ > > Key: DROOLS-694 > URL: https://issues.jboss.org/browse/DROOLS-694 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR4 > Environment: fail with PHREAK, work correctly as expected with RETEOO > Reporter: Matteo Mortari > Assignee: Mark Proctor > Attachments: 20150121.accumulate-window-counter.zip > > > With reference to attached reproducer. > Assuming the following KB, where to goal is to keep a {{Counter}} fact for the amount of {{Measurement}} events received in the last hour. > {code:java} > declare Measurement > @role(event) > end > rule "Init Counter last 1h" > agenda-group "USERSPACE" > salience 1 > no-loop > when > not Counter( name == "Counter last 1h" ) > then > Counter c = new Counter("Counter last 1h", 0); > insert(c); > System.out.println("RHS Init Counter last 1h " + c); > end > rule "Update Counter last 1h" > agenda-group "USERSPACE" > no-loop > when > accumulate( $token : Measurement() over window:time( 1h ) ; > $val : count($token) > ) > $cv1 : Counter( name == "Counter last 1h", value != $val.doubleValue() ) > then > int count = $val.intValue(); > $cv1.setValue(count); > update($cv1); > System.out.println("RHS Update Counter last 1h : "+$cv1); > end > {code} > The following Unit test shall have the effect in the end to obtain value 2.0 in the {{Counter}} object, as I've inserted 2 {{MEasurement}} within the last hour and within two minutes > {code:java} > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "220")); > fire(session); > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "221")); > fire(session); > LOG.info("Final checks"); > Counter counter = (Counter) session.getObjects(counterFilter).iterator().next(); // I'm taking a shortcut as for this reproducer I know there is only 1 Counter in WM > assertEquals("I've inserted 2 Measurement within the hour ", 2, counter.getValue(), 0); > {code} > However this works only with ReteOO and the test FAILS with Phreak. > Can you kindly advise, please? > Thank you > MM -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-672) Drools audit log view cannot be opened

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-672?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-672. -------------------------------- Fix Version/s: 6.2.0.Final Resolution: Duplicate Issue This issue has been already reported here https://bugzilla.redhat.com/show_bug.cgi?id=1117954 and fixed with this commit https://github.com/droolsjbpm/drools/commit/5e05721f4a81d9f80285c0dc1216d... > Drools audit log view cannot be opened > -------------------------------------- > > Key: DROOLS-672 > URL: https://issues.jboss.org/browse/DROOLS-672 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.1.Final > Reporter: Jose Luis Melgar > Assignee: Mario Fusco > Labels: Drools > Fix For: 6.2.0.Final > > > On behalf of Gergely Bacso: > {quote} > From: Mark Proctor > Sent: ‎20/‎12/‎2014 21:15 > To: drools-setup(a)googlegroups.com > Cc: Bob Brodt > Subject: Re: [drools-setup] Drools audit log view cannot be opened > please open a JIRA, so we can be sure to fix this. > Thanks > Mark > {quote} > {quote} > On 19 Dec 2014, at 18:19, Gergely Bacsó wrote: > Hi, > First of all: this problem can be reproduced with only a single audit file. > I managed to get closer to the solution by spending a few hours reading Drools source code: > The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up: > http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop()) > Since my audit logs for some reason contain several of > AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays. > Gergely > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-698) GlobalDateExtractor should not use java.sql.Date

by Tibor Foris (JIRA)

[ https://issues.jboss.org/browse/DROOLS-698?page=com.atlassian.jira.plugin... ] Tibor Foris commented on DROOLS-698: ------------------------------------ Thank you. Regards, Tibor > GlobalDateExtractor should not use java.sql.Date > ------------------------------------------------ > > Key: DROOLS-698 > URL: https://issues.jboss.org/browse/DROOLS-698 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Tibor Foris > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > > The GlobalDateExtractor class uses java.sql.Date instead of java.util.Date. > This leads to class cast exceptions (java.sql.Date against java.util.Date) when using globals of type date (java.util.Date). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-672) Drools audit log view cannot be opened

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-672?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-672: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > Drools audit log view cannot be opened > -------------------------------------- > > Key: DROOLS-672 > URL: https://issues.jboss.org/browse/DROOLS-672 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.1.Final > Reporter: Jose Luis Melgar > Assignee: Mario Fusco > Labels: Drools > > On behalf of Gergely Bacso: > {quote} > From: Mark Proctor > Sent: ‎20/‎12/‎2014 21:15 > To: drools-setup(a)googlegroups.com > Cc: Bob Brodt > Subject: Re: [drools-setup] Drools audit log view cannot be opened > please open a JIRA, so we can be sure to fix this. > Thanks > Mark > {quote} > {quote} > On 19 Dec 2014, at 18:19, Gergely Bacsó wrote: > Hi, > First of all: this problem can be reproduced with only a single audit file. > I managed to get closer to the solution by spending a few hours reading Drools source code: > The Eclipse plugin has a class called AuditView, this class expects RuleFlowGroupNode-s in the right sequence, or it blows up: > http://grepcode.com/file/repo1.maven.org/maven2/org.drools/org.drools.ecl... (see line 515, stack.pop()) > Since my audit logs for some reason contain several of > AFTER_RULEFLOW_GROUP_DEACTIVATED entries without having any BEFORE_RULEFLOW_GROUP_DEACTIVATED entries preceding them, the AuditView fails to parse the log.Currently I am manually removing these non-matched entries to be able to open the file, and planning to spend some time on further analysis after the holidays. > Gergely > {quote} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-698) GlobalDateExtractor should not use java.sql.Date

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-698?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-698. -------------------------------- Fix Version/s: 6.2.0.Final Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/9612e92c7 > GlobalDateExtractor should not use java.sql.Date > ------------------------------------------------ > > Key: DROOLS-698 > URL: https://issues.jboss.org/browse/DROOLS-698 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Tibor Foris > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > > The GlobalDateExtractor class uses java.sql.Date instead of java.util.Date. > This leads to class cast exceptions (java.sql.Date against java.util.Date) when using globals of type date (java.util.Date). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-772) SPNEGOLoginModule does not always respect removeRealmFromPrincipal

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-772?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-772: -------------------------------------------------- Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1039989|https://bugzilla.redhat.com/show_bug.cgi?id=1039989] from ON_QA to VERIFIED > SPNEGOLoginModule does not always respect removeRealmFromPrincipal > ------------------------------------------------------------------ > > Key: SECURITY-772 > URL: https://issues.jboss.org/browse/SECURITY-772 > Project: PicketBox > Issue Type: Bug > Components: Negotiation > Affects Versions: Negotiation_2_2_6 > Reporter: Tom Fonteyne > Assignee: Tom Fonteyne > Priority: Minor > Fix For: Negotiation_2_2_7 > > > org.jboss.security.negotiation.spnego.SPNEGOLoginModule > private class AcceptSecContext: > if (gssContext.isEstablished()) > { > log.warn("Authentication was performed despite already being authenticated!"); > // TODO - Refactor to only do this once. > setIdentity(new KerberosPrincipal(gssContext.getSrcName().toString())); > The last line should obey the "removeRealmFromPrincipal" flag similarly as a bit further down: > setIdentity(createIdentity(gssContext.getSrcName().toString())); -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-698) GlobalDateExtractor should not use java.sql.Date

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-698?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-698: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > GlobalDateExtractor should not use java.sql.Date > ------------------------------------------------ > > Key: DROOLS-698 > URL: https://issues.jboss.org/browse/DROOLS-698 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Reporter: Tibor Foris > Assignee: Mario Fusco > > The GlobalDateExtractor class uses java.sql.Date instead of java.util.Date. > This leads to class cast exceptions (java.sql.Date against java.util.Date) when using globals of type date (java.util.Date). -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Description: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{ (char) }} operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} was: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{(char)}} operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {/code} > ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates > ----------------------------------------------------------------- > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. > (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{ (char) }} operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Description: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} was: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and {{ (char) }} operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} > ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates > ----------------------------------------------------------------- > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. > (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 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 January 2015