[JBoss JIRA] (DROOLS-688) coincides temporal operator issue when combined with not and duration
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-688?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-688:
----------------------------------
Description:
_Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
h5. Executive summary
I would like to report two issues
_Main Issue_. Given the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin || this before[10s] $yin )
{code}
I understood this could have been simplified into
{code:java}
not Yang( this coincides[10s] $yin )
{code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
_Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
h5. Description
Reference is made to attached reproducer. Assume the following KB:
{code:java}
declare Yin
@role(event)
end
declare Yang
@role(event)
end
declare ErrorToken
@role(event)
origin : Yin
end
rule "Yin is missing Yang balance"
duration 10000
agenda-group "USERSPACE"
no-loop
when
$yin : Yin()
not ErrorToken(origin : $yin)
not Yang( this after[10s] $yin || this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
then
System.out.println("Rule RHS: Yin is missing Yang balance");
ErrorToken token = new ErrorToken();
token.setOrigin($yin);
insert(token);
end
{code}
In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
Hence the test suite is aimed at verifying two main use-cases.
First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 1, TimeUnit.SECONDS);
insert(session, new Yang());
fire(session);
assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
{code}
Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 30, TimeUnit.SECONDS);
insert(session, new Yin());
fire(session);
assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
{code}
You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
h5. Reproduce the problem.
_Main Issue_. Change the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin || this before[10s] $yin )
{code}
into
{code:java}
not Yang( this coincides[10s] $yin )
{code}
which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
_Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
Can you kindly advise, please?
Thank you
was:
_Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
h5. Executive summary
I would like to report two issues
_Main Issue_. Given the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin || this before[10s] $yin )
{code}
I understood this could have been simplified into
{code:java}
not Yang( this coincides[10s] $yin )
{code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
_Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
h5. Description
Reference is made to attached reproducer. Assume the following KB:
{code:java}
declare Yin
@role(event)
end
declare Yang
@role(event)
end
declare ErrorToken
@role(event)
origin : Yin
end
rule "Yin is missing Yang balance"
duration 10000
agenda-group "USERSPACE"
no-loop
when
$yin : Yin()
not ErrorToken(origin : $yin)
not Yang( this after[10s] $yin, this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
then
System.out.println("Rule RHS: Yin is missing Yang balance");
ErrorToken token = new ErrorToken();
token.setOrigin($yin);
insert(token);
end
{code}
In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
Hence the test suite is aimed at verifying two main use-cases.
First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 1, TimeUnit.SECONDS);
insert(session, new Yang());
fire(session);
assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
{code}
Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 30, TimeUnit.SECONDS);
insert(session, new Yin());
fire(session);
assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
{code}
You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
h5. Reproduce the problem.
_Main Issue_. Change the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin || this before[10s] $yin )
{code}
into
{code:java}
not Yang( this coincides[10s] $yin )
{code}
which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
_Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
Can you kindly advise, please?
Thank you
> coincides temporal operator issue when combined with not and duration
> ---------------------------------------------------------------------
>
> Key: DROOLS-688
> URL: https://issues.jboss.org/browse/DROOLS-688
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR4
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20150115.drools6test-duration-not-coincides.zip, 20150115bis.drools6test-duration-not-coincides.zip
>
>
> _Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
> h5. Executive summary
> I would like to report two issues
> _Main Issue_. Given the following condition in LHS:
> {code:java}
> not Yang( this after[10s] $yin || this before[10s] $yin )
> {code}
> I understood this could have been simplified into
> {code:java}
> not Yang( this coincides[10s] $yin )
> {code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
> _Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
> h5. Description
> Reference is made to attached reproducer. Assume the following KB:
> {code:java}
> declare Yin
> @role(event)
> end
> declare Yang
> @role(event)
> end
> declare ErrorToken
> @role(event)
> origin : Yin
> end
> rule "Yin is missing Yang balance"
> duration 10000
> agenda-group "USERSPACE"
> no-loop
> when
> $yin : Yin()
> not ErrorToken(origin : $yin)
> not Yang( this after[10s] $yin || this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
> then
> System.out.println("Rule RHS: Yin is missing Yang balance");
> ErrorToken token = new ErrorToken();
> token.setOrigin($yin);
> insert(token);
> end
> {code}
> In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
> Hence the test suite is aimed at verifying two main use-cases.
> First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Yin());
> fire(session);
> assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
> advance(clock, 1, TimeUnit.SECONDS);
> insert(session, new Yang());
> fire(session);
> assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
> {code}
> Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Yin());
> fire(session);
> assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
> advance(clock, 30, TimeUnit.SECONDS);
> insert(session, new Yin());
> fire(session);
> assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
> {code}
> You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
> h5. Reproduce the problem.
> _Main Issue_. Change the following condition in LHS:
> {code:java}
> not Yang( this after[10s] $yin || this before[10s] $yin )
> {code}
> into
> {code:java}
> not Yang( this coincides[10s] $yin )
> {code}
> which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
> _Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
> Can you kindly advise, please?
> Thank you
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-504) RBAC does not let server-group scoped roles read all hosts
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-504?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-504:
------------------------------------------------
Brian Stansberry <brian.stansberry(a)redhat.com> changed the Status of [bug 1178810|https://bugzilla.redhat.com/show_bug.cgi?id=1178810] from ASSIGNED to POST
> RBAC does not let server-group scoped roles read all hosts
> ----------------------------------------------------------
>
> Key: WFCORE-504
> URL: https://issues.jboss.org/browse/WFCORE-504
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha15
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> The RBAC implementation is not allowing a server-group scoped role to read resources in the host=* tree unless one of these is true:
> 1) the host only contains a server mapped to the server group
> 2) the host doesn't contain any servers.
> This is consistent with handling of other "mappable" things but is contrary to the docs, which declare
> "In addition to these privileges, users in a server-group scoped role will have non-sensitive read privileges (equivalent to the Monitor role) for resources other than those listed above."
> but don't list these host resources.
> It's also unintuitive, as the s-g-s-r is actually allowed to add a server on the host, but can't read the other host resources before doing so.
> Also, asking the DC for the list of host names will include the host, but trying to read its root resource will result in a NoSuchResourceException.
> The issue dates back to 8.0, but recent changes to the console have resulted in this breaking console behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-688) coincides temporal operator issue when combined with not and duration
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-688?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-688:
----------------------------------
Attachment: 20150115bis.drools6test-duration-not-coincides.zip
Oups, sorry I meant after and before temporal operators be separated by OR, not by comma.
> coincides temporal operator issue when combined with not and duration
> ---------------------------------------------------------------------
>
> Key: DROOLS-688
> URL: https://issues.jboss.org/browse/DROOLS-688
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR4
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20150115.drools6test-duration-not-coincides.zip, 20150115bis.drools6test-duration-not-coincides.zip
>
>
> _Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
> h5. Executive summary
> I would like to report two issues
> _Main Issue_. Given the following condition in LHS:
> {code:java}
> not Yang( this after[10s] $yin || this before[10s] $yin )
> {code}
> I understood this could have been simplified into
> {code:java}
> not Yang( this coincides[10s] $yin )
> {code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
> _Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
> h5. Description
> Reference is made to attached reproducer. Assume the following KB:
> {code:java}
> declare Yin
> @role(event)
> end
> declare Yang
> @role(event)
> end
> declare ErrorToken
> @role(event)
> origin : Yin
> end
> rule "Yin is missing Yang balance"
> duration 10000
> agenda-group "USERSPACE"
> no-loop
> when
> $yin : Yin()
> not ErrorToken(origin : $yin)
> not Yang( this after[10s] $yin, this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
> then
> System.out.println("Rule RHS: Yin is missing Yang balance");
> ErrorToken token = new ErrorToken();
> token.setOrigin($yin);
> insert(token);
> end
> {code}
> In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
> Hence the test suite is aimed at verifying two main use-cases.
> First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Yin());
> fire(session);
> assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
> advance(clock, 1, TimeUnit.SECONDS);
> insert(session, new Yang());
> fire(session);
> assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
> {code}
> Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Yin());
> fire(session);
> assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
> advance(clock, 30, TimeUnit.SECONDS);
> insert(session, new Yin());
> fire(session);
> assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
> {code}
> You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
> h5. Reproduce the problem.
> _Main Issue_. Change the following condition in LHS:
> {code:java}
> not Yang( this after[10s] $yin || this before[10s] $yin )
> {code}
> into
> {code:java}
> not Yang( this coincides[10s] $yin )
> {code}
> which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
> _Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
> Can you kindly advise, please?
> Thank you
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-688) coincides temporal operator issue when combined with not and duration
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-688?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-688:
----------------------------------
Description:
_Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
h5. Executive summary
I would like to report two issues
_Main Issue_. Given the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin || this before[10s] $yin )
{code}
I understood this could have been simplified into
{code:java}
not Yang( this coincides[10s] $yin )
{code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
_Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
h5. Description
Reference is made to attached reproducer. Assume the following KB:
{code:java}
declare Yin
@role(event)
end
declare Yang
@role(event)
end
declare ErrorToken
@role(event)
origin : Yin
end
rule "Yin is missing Yang balance"
duration 10000
agenda-group "USERSPACE"
no-loop
when
$yin : Yin()
not ErrorToken(origin : $yin)
not Yang( this after[10s] $yin, this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
then
System.out.println("Rule RHS: Yin is missing Yang balance");
ErrorToken token = new ErrorToken();
token.setOrigin($yin);
insert(token);
end
{code}
In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
Hence the test suite is aimed at verifying two main use-cases.
First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 1, TimeUnit.SECONDS);
insert(session, new Yang());
fire(session);
assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
{code}
Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 30, TimeUnit.SECONDS);
insert(session, new Yin());
fire(session);
assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
{code}
You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
h5. Reproduce the problem.
_Main Issue_. Change the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin || this before[10s] $yin )
{code}
into
{code:java}
not Yang( this coincides[10s] $yin )
{code}
which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
_Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
Can you kindly advise, please?
Thank you
was:
_Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
h5. Executive summary
I would like to report two issues
_Main Issue_. Given the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin, this before[10s] $yin )
{code}
I understood this could have been simplified into
{code:java}
not Yang( this coincides[10s] $yin )
{code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
_Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
h5. Description
Reference is made to attached reproducer. Assume the following KB:
{code:java}
declare Yin
@role(event)
end
declare Yang
@role(event)
end
declare ErrorToken
@role(event)
origin : Yin
end
rule "Yin is missing Yang balance"
duration 10000
agenda-group "USERSPACE"
no-loop
when
$yin : Yin()
not ErrorToken(origin : $yin)
not Yang( this after[10s] $yin, this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
then
System.out.println("Rule RHS: Yin is missing Yang balance");
ErrorToken token = new ErrorToken();
token.setOrigin($yin);
insert(token);
end
{code}
In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
Hence the test suite is aimed at verifying two main use-cases.
First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 1, TimeUnit.SECONDS);
insert(session, new Yang());
fire(session);
assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
{code}
Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 30, TimeUnit.SECONDS);
insert(session, new Yin());
fire(session);
assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
{code}
You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
h5. Reproduce the problem.
_Main Issue_. Change the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin, this before[10s] $yin )
{code}
into
{code:java}
not Yang( this coincides[10s] $yin )
{code}
which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
_Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
Can you kindly advise, please?
Thank you
> coincides temporal operator issue when combined with not and duration
> ---------------------------------------------------------------------
>
> Key: DROOLS-688
> URL: https://issues.jboss.org/browse/DROOLS-688
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR4
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20150115.drools6test-duration-not-coincides.zip
>
>
> _Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
> h5. Executive summary
> I would like to report two issues
> _Main Issue_. Given the following condition in LHS:
> {code:java}
> not Yang( this after[10s] $yin || this before[10s] $yin )
> {code}
> I understood this could have been simplified into
> {code:java}
> not Yang( this coincides[10s] $yin )
> {code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
> _Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
> h5. Description
> Reference is made to attached reproducer. Assume the following KB:
> {code:java}
> declare Yin
> @role(event)
> end
> declare Yang
> @role(event)
> end
> declare ErrorToken
> @role(event)
> origin : Yin
> end
> rule "Yin is missing Yang balance"
> duration 10000
> agenda-group "USERSPACE"
> no-loop
> when
> $yin : Yin()
> not ErrorToken(origin : $yin)
> not Yang( this after[10s] $yin, this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
> then
> System.out.println("Rule RHS: Yin is missing Yang balance");
> ErrorToken token = new ErrorToken();
> token.setOrigin($yin);
> insert(token);
> end
> {code}
> In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
> Hence the test suite is aimed at verifying two main use-cases.
> First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Yin());
> fire(session);
> assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
> advance(clock, 1, TimeUnit.SECONDS);
> insert(session, new Yang());
> fire(session);
> assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
> {code}
> Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Yin());
> fire(session);
> assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
> advance(clock, 30, TimeUnit.SECONDS);
> insert(session, new Yin());
> fire(session);
> assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
> {code}
> You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
> h5. Reproduce the problem.
> _Main Issue_. Change the following condition in LHS:
> {code:java}
> not Yang( this after[10s] $yin || this before[10s] $yin )
> {code}
> into
> {code:java}
> not Yang( this coincides[10s] $yin )
> {code}
> which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
> _Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
> Can you kindly advise, please?
> Thank you
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-688) coincides temporal operator issue when combined with not and duration
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-688?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-688:
----------------------------------
Attachment: 20150115.drools6test-duration-not-coincides.zip
attaching the reproducer as described
> coincides temporal operator issue when combined with not and duration
> ---------------------------------------------------------------------
>
> Key: DROOLS-688
> URL: https://issues.jboss.org/browse/DROOLS-688
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR4
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20150115.drools6test-duration-not-coincides.zip
>
>
> _Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
> h5. Executive summary
> I would like to report two issues
> _Main Issue_. Given the following condition in LHS:
> {code:java}
> not Yang( this after[10s] $yin, this before[10s] $yin )
> {code}
> I understood this could have been simplified into
> {code:java}
> not Yang( this coincides[10s] $yin )
> {code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
> _Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
> h5. Description
> Reference is made to attached reproducer. Assume the following KB:
> {code:java}
> declare Yin
> @role(event)
> end
> declare Yang
> @role(event)
> end
> declare ErrorToken
> @role(event)
> origin : Yin
> end
> rule "Yin is missing Yang balance"
> duration 10000
> agenda-group "USERSPACE"
> no-loop
> when
> $yin : Yin()
> not ErrorToken(origin : $yin)
> not Yang( this after[10s] $yin, this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
> then
> System.out.println("Rule RHS: Yin is missing Yang balance");
> ErrorToken token = new ErrorToken();
> token.setOrigin($yin);
> insert(token);
> end
> {code}
> In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
> Hence the test suite is aimed at verifying two main use-cases.
> First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Yin());
> fire(session);
> assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
> advance(clock, 1, TimeUnit.SECONDS);
> insert(session, new Yang());
> fire(session);
> assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
> {code}
> Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
> {code:java}
> advance(clock, 1, TimeUnit.MINUTES);
> insert(session, new Yin());
> fire(session);
> assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
> advance(clock, 30, TimeUnit.SECONDS);
> insert(session, new Yin());
> fire(session);
> assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
> {code}
> You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
> h5. Reproduce the problem.
> _Main Issue_. Change the following condition in LHS:
> {code:java}
> not Yang( this after[10s] $yin, this before[10s] $yin )
> {code}
> into
> {code:java}
> not Yang( this coincides[10s] $yin )
> {code}
> which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
> _Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
> Can you kindly advise, please?
> Thank you
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-688) coincides temporal operator issue when combined with not and duration
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-688:
-------------------------------------
Summary: coincides temporal operator issue when combined with not and duration
Key: DROOLS-688
URL: https://issues.jboss.org/browse/DROOLS-688
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.CR4, 6.1.0.Final
Reporter: Matteo Mortari
Assignee: Mark Proctor
_Premise_: this is assuming in case of Point/Point event comparison, the combination of {{after\[delta\]}} + {{before\[delta\]}} could be simplified into {{coincides\[delta\]}}. If not the case, there is still one case failing (using 6.2.0.CR4) and imho worth reporting.
h5. Executive summary
I would like to report two issues
_Main Issue_. Given the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin, this before[10s] $yin )
{code}
I understood this could have been simplified into
{code:java}
not Yang( this coincides[10s] $yin )
{code} assuming Yang and $yin are both Point events (start coincides with end). The reproducer I will attach demonstrate IFF I put in the first form, it does work as expected and all test are passing; however if using the latter form, test would fail.
_Second issue_. Even assuming the first form, using version 6.2.0.CR4 would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
h5. Description
Reference is made to attached reproducer. Assume the following KB:
{code:java}
declare Yin
@role(event)
end
declare Yang
@role(event)
end
declare ErrorToken
@role(event)
origin : Yin
end
rule "Yin is missing Yang balance"
duration 10000
agenda-group "USERSPACE"
no-loop
when
$yin : Yin()
not ErrorToken(origin : $yin)
not Yang( this after[10s] $yin, this before[10s] $yin ) // shouldn't this be equivalent to: not Yang( this coincides[10s] $yin ) ?
then
System.out.println("Rule RHS: Yin is missing Yang balance");
ErrorToken token = new ErrorToken();
token.setOrigin($yin);
insert(token);
end
{code}
In other words, if a Yin event is detected, there shall be a Yang event either 10s before or 10s after, otherwise an ErrorToken is inserted because of this missing balance.
Hence the test suite is aimed at verifying two main use-cases.
First use case, in case Yin is followed by a Yang, the balance is correct, hence no ErrorToken shall be issued:
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 1, TimeUnit.SECONDS);
insert(session, new Yang());
fire(session);
assertEquals("As I provided an Yang, there should be no errors", 0, session.getObjects(errorTokenFilter).size());
{code}
Second use case, in case Yin is issued and NO Yang is issued, an ErrorToken shall indeed be present signifying the first Yin has no balance
{code:java}
advance(clock, 1, TimeUnit.MINUTES);
insert(session, new Yin());
fire(session);
assertEquals("I fired an Error too early", 0, session.getObjects(errorTokenFilter).size());
advance(clock, 30, TimeUnit.SECONDS);
insert(session, new Yin());
fire(session);
assertEquals("Now I should be certain for the first Yin there should be 1 error", 1, session.getObjects(errorTokenFilter).size());
{code}
You can also check that even without inserting the second Yin, the test suite is passing all test as intended.
h5. Reproduce the problem.
_Main Issue_. Change the following condition in LHS:
{code:java}
not Yang( this after[10s] $yin, this before[10s] $yin )
{code}
into
{code:java}
not Yang( this coincides[10s] $yin )
{code}
which basically should signify: _There is missing a Yang in the temporal neighbourhood of 10s when Yin happened_. Now the test suite will fail the tests.
_Second issue_. Even assuming the first form, hence leaving UNchanged the KB as originally provided in the reproducer. Now go to the pom.xml and change drools-version property in order to be using version 6.2.0.CR4 . Then test suite would fail when using phreak and TimedRuleExectionOption because NETWORK_EVALUATOR.evaluateNetwork() in RuleExecutor would not terminate.
Can you kindly advise, please?
Thank you
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-503) Child resources under the deployment=XXX resource should be marked as runtime-only
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-503?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-503:
-----------------------------------------
Hi Tomaz,
Please coordinate with Harald or Heiko on this so we don't break the console. There's probably no issue, but if there is all they need to do is add include-runtime=true to requests that want to read below the deployment=* node.
> Child resources under the deployment=XXX resource should be marked as runtime-only
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-503
> URL: https://issues.jboss.org/browse/WFCORE-503
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha15
> Reporter: Brian Stansberry
> Assignee: Tomaz Cerar
>
> Underneath a deployment resource there can be a large tree of runtime-only resources. Those resources are not getting the correct value for their isRuntime() property.
> DeploymentModelUtils.getOrCreate() should call Resource.Factory.create(true) instead of just Resource.Factory.create().
> Note this may break the console if it is doing a recursive read of deployment resources and not including the include-runtime=true param.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-506) Incoherence in core dist between domain.xml and host(-slave).xml
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-506?page=com.atlassian.jira.plugin... ]
Emmanuel Hugonnet updated WFCORE-506:
-------------------------------------
Description:
host.xml and host-slave.xml reference a other-server-group which is not defined in domain.xml.
Provide either correct host files or domain.xml to be able to use the dist in domain mode.
> Incoherence in core dist between domain.xml and host(-slave).xml
> -----------------------------------------------------------------
>
> Key: WFCORE-506
> URL: https://issues.jboss.org/browse/WFCORE-506
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha15
> Reporter: Emmanuel Hugonnet
> Assignee: Emmanuel Hugonnet
> Priority: Trivial
>
> host.xml and host-slave.xml reference a other-server-group which is not defined in domain.xml.
> Provide either correct host files or domain.xml to be able to use the dist in domain mode.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months