[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ]
Davide Sottara edited comment on DROOLS-702 at 1/31/15 9:54 AM:
----------------------------------------------------------------
When a rule extends another, patterns will not be merged.
If you have:
{code} rule "parent" when $p : Person() then end {code}
and
{code} rule "child" when Person() then end {code}
the engine cannot safely infer that those two patterns should match the
SAME fact, so you end up with a cross-product of two patterns.
In your reproducer, the number of firings is consistent with the cross
product of the facts you inserted, so I don't see any bug here.
As an alternative to "from", you can use unification:
{code} $p := Person() {code}
in both rules (parent and child) to ensure the two patterns are linked.
[Edit: clarification: "from" ensures the pattern applied to the same object,
while ":=" is still affected by equality]
was (Author: dsotty):
When a rule extends another, patterns will not be merged.
If you have:
{code} rule "parent" when $p : Person() then end {code}
and
{code} rule "child" when Person() then end {code}
the engine cannot safely infer that those two patterns should match the
SAME fact, so you end up with a cross-product of two patterns.
In your reproducer, the number of firings is consistent with the cross
product of the facts you inserted, so I don't see any bug here.
As an alternative to "from", you can use unification:
{code} $p := Person() {code}
in both rules (parent and child) to ensure the two patterns are linked.
> Rule Inheritance fired the sub rule even the condition doen't match
> -------------------------------------------------------------------
>
> Key: DROOLS-702
> URL: https://issues.jboss.org/browse/DROOLS-702
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: Windows, Java6.0.29
> Reporter: Yacine Jaber
> Assignee: Davide Sottara
> Priority: Critical
> Attachments: wod-drools-test.7z
>
>
> You can find the attached a simple maven project that shows this error.
> You can run ExampleDrools class as main java application.
> The sub rules are fired even if the condition is not matched.
> There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
> This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (ELY-139) Appending into ByteStringBuilder fail if initial array blank
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}
> Appending into ByteStringBuilder fail if initial array blank
> ------------------------------------------------------------
>
> 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)
9 years, 8 months
[JBoss JIRA] (ELY-139) Appending into ByteStringBuilder fail if initial array blank
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-139:
---------------------------
Summary: Appending into ByteStringBuilder fail if initial array blank (was: ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates)
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}
> Appending into ByteStringBuilder fail if initial array blank
> ------------------------------------------------------------
>
> 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)
9 years, 8 months
[JBoss JIRA] (DROOLS-695) Add ability to disable rules
by Stephen Slaboda (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Stephen Slaboda closed DROOLS-695.
----------------------------------
Resolution: Rejected
This functionality already exists in Drools and in the Workbench (the "enabled" option for a rule satisfies the requested capability)
> Add ability to disable rules
> ----------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (DROOLS-695) Add ability to disable rules
by Stephen Slaboda (JIRA)
[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ]
Stephen Slaboda commented on DROOLS-695:
----------------------------------------
I just discovered that the workbench provides the ability to specify an "enabled" option on a rule, allowing you to disable the rule. This satisfies my criteria, so I am closing this issue.
> Add ability to disable rules
> ----------------------------
>
> Key: DROOLS-695
> URL: https://issues.jboss.org/browse/DROOLS-695
> Project: Drools
> Issue Type: Enhancement
> Affects Versions: 6.2.0.CR4
> Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5
> Reporter: Stephen Slaboda
> Labels: drools-wb
>
> Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be:
> -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing)
> -Turn off rules if it is determined that they are impacitng the operational environment
> -Allow development of rules in the same space while not breaking the build/deploy of rules
> -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rafael Benevides commented on WFLY-4171:
----------------------------------------
Thanks [~fbricon] I'll close it Monday after I update stacks.yaml.
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Fred Bricon commented on WFLY-4171:
-----------------------------------
Everything finally looks good! Yeah \o/
+1 to release
Thanks Rafa
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 8 months