January 2015 - jboss-jira - Jboss List Archives

[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, 10 months

1
0
0 / 0

[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 resolved ELY-139. ---------------------------- Resolution: Done > 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, 10 months

1
0
0 / 0

[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: --------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/101 > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3351) WildFly self-monitoring (history storage + REST API + web console plugin)

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-3351?page=com.atlassian.jira.plugin.... ] Ondrej Zizka commented on WFLY-3351: ------------------------------------ The result - a prototype - is at https://is.muni.cz/th/325163/fi_m/?furl=%2Fth%2F325163%2Ffi_m%2F;so=nx;la... For docs see the text of the thesis (in English), for working configured server download the Appendix. > WildFly self-monitoring (history storage + REST API + web console plugin) > ------------------------------------------------------------------------- > > Key: WFLY-3351 > URL: https://issues.jboss.org/browse/WFLY-3351 > Project: WildFly > Issue Type: Feature Request > Components: Logging > Reporter: Ondrej Zizka > Assignee: James Perkins > > Would be nice if WildFly had it's optional own submodule which would monitor the AS, store the data, and allow it's retrieval later through REST API. Also, the console could have a plugin to read and display these data. > This was discussed some time ago as one of requirements by different parties - JON, JBDS, end users. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 10 months

1
0
0 / 0

[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, 10 months

1
0
0 / 0

[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, 10 months

1
0
0 / 0

[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, 10 months

1
0
0 / 0

[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, 10 months

1
0
0 / 0

[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, 10 months

1
0
0 / 0

[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, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2015