January 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2853) ResourceFactory.newClassPathResource(drlPath) behaves differently on different platforms (linux, windows): it parses the file with different encodings

by Geoffrey De Smet (JIRA)

ResourceFactory.newClassPathResource(drlPath) behaves differently on different platforms (linux, windows): it parses the file with different encodings ------------------------------------------------------------------------------------------------------------------------------------------------------ Key: JBRULES-2853 URL: https://issues.jboss.org/browse/JBRULES-2853 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Geoffrey De Smet Assignee: Mark Proctor Priority: Critical This really sucks for non English people :) English people write in pure ASCII, so they don't suffer from this problem. French, Dutch etc mix in Latin-1 chars. Russian, Chinese use something else. The root problem: There are 2 ways to create an InputStream: - with encoding = GOOD, use encoding "UTF-8" and there are no problems. - without encoding: use the default platform encoding = BAD -- Linux: UTF-8, Windows in Belgium: Latin-1, Windows in China: Chinese-1, Windows in Sweden: Latin-2, ... -- Java's InputStream should have just defaulted it on UTF-8 Proposition 1: Overloaded method which has an extra String encoding: - ResourceFactory.newClassPathResource(drlPath, encoding) - similar tactic as InputStream Proposition 2: Keep it simple. We decide what a DRL file is. Just like an XML file says to hell with the specified encoding, so can we. Note: All XML files default to UTF-8 encoding, and you can overwrite it in a header in the XML file itself (= self-describing): no need to mess around in the java code. Same principle: All DRL files are default UTF-8 encoding. Optionally we can define an encoding header later. I strongly prefer proposition 2. The world has got enough encoding problems. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
15
0 / 0

[JBoss JIRA] Created: (JBRULES-3173) drools-compiler depends on antlr 2.7.7

by Marcel May (JIRA)

drools-compiler depends on antlr 2.7.7 -------------------------------------- Key: JBRULES-3173 URL: https://issues.jboss.org/browse/JBRULES-3173 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.3.0.Beta1, 5.2.0.Final Reporter: Marcel May Assignee: Mark Proctor Priority: Trivial drools-compiler uses antlr 3.3 but has an additional dependency on old antlr:antlr 2.7.7 version. The v2 dependency is obsolete since antlr 3.1 (see http://www.antlr.org/jira/browse/ANTLR-180). Please remove the antlr:antlr dependency, for the next 5.2.x / 5.3.x release - thanks! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

4
9
0 / 0

[JBoss JIRA] (AS7-2868) Get rid of subsystem element attributes in infinispan 1.1. xsd

by Kabir Khan (Created) (JIRA)

Get rid of subsystem element attributes in infinispan 1.1. xsd -------------------------------------------------------------- Key: AS7-2868 URL: https://issues.jboss.org/browse/AS7-2868 Project: Application Server 7 Issue Type: Feature Request Components: Clustering Reporter: Kabir Khan Assignee: Paul Ferraro Fix For: 7.1.0.CR1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

4
4
0 / 0

[JBoss JIRA] (JBRULES-3263) Implement evaluation of alpha nodes constraints with MVEL and ASM

by Mario Fusco (Created) (JIRA)

Implement evaluation of alpha nodes constraints with MVEL and ASM ----------------------------------------------------------------- Key: JBRULES-3263 URL: https://issues.jboss.org/browse/JBRULES-3263 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco Replace the LiteralConstraint we have at the moment (based on a big number of very specialized Evaluators that imply a lot of code duplication) with one that only uses MVEL to evaluate the constraints in the alpha nodes. As a second step add a counter on each of this constraints and optimize the ones that are invoked more frequently by jitting them with ASM -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
1
0 / 0

[JBoss JIRA] (JBRULES-3365) Allow the KnowledgeBuilder to build more than one DRL at time regardless of their ordering

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3365: ------------------------------------ Summary: Allow the KnowledgeBuilder to build more than one DRL at time regardless of their ordering Key: JBRULES-3365 URL: https://issues.jboss.org/browse/JBRULES-3365 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-3231) Tidy up Generated Invokers

by Mark Proctor (JIRA)

Tidy up Generated Invokers -------------------------- Key: JBRULES-3231 URL: https://issues.jboss.org/browse/JBRULES-3231 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor Where possible the tuple.parent loop should be unrolled. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1917) JBRMS does not support business rules with non ascii characters

by Gregory Chazalon (JIRA)

JBRMS does not support business rules with non ascii characters --------------------------------------------------------------- Key: JBRULES-1917 URL: https://jira.jboss.org/jira/browse/JBRULES-1917 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.7 Reporter: Gregory Chazalon Assignee: Mark Proctor A very simple rule containing some Latin1 characters (e.g. 'é', 'à'..), is not compiled correctly when using the JBRMS web app. The exact same rule defined in a DRL file, and compiled with the drools compiler API is well handled (no characters mismatch). Actually, the rule defined both ways is : {code} rule "latin_message" when Let information message then information message containing latin characters léger problème à résoudre hôpital end {/code} I strongly suspect a poor character encoding scheme inside the JBRMS code, but I haven't been able to identify it. The problem is illustrated by the LatinMessageTest test case, bundled inside the small eclipse project provided. It has two test methods, one building the rule using the drools compiler API, and the other using a binary package built with JBRMS. The second one fails as of the poor character encoding suspected inside JBRMS web app. Any help is appreciated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-3166) Improve the support for monitoring/conformance rules

by Davide Sottara (JIRA)

Improve the support for monitoring/conformance rules ----------------------------------------------------- Key: JBRULES-3166 URL: https://issues.jboss.org/browse/JBRULES-3166 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core (expert), drools-core (fusion) Reporter: Davide Sottara Assignee: Mark Proctor Priority: Optional Often, rules are written to monitor the state of a system. When the state (does not) matches the expressed conditions, appropriate actions are taken. In addition, notification events could/should be generated for further processing. Drools could provide a dedicated syntax to facilitate the authoring of such rules. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1602) The order of RHS statements shouldn't affect behavior (insertLogical)

by Patrick Gras (JIRA)

The order of RHS statements shouldn't affect behavior (insertLogical) --------------------------------------------------------------------- Key: JBRULES-1602 URL: http://jira.jboss.com/jira/browse/JBRULES-1602 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Environment: Drools 4.0.7 & 4.0.4, Java5, eclipse compiler, windows XP. Reporter: Patrick Gras Assigned To: Mark Proctor I have a class 'Cat' that is dynamic (JavaBean with PropertyChangeSupport ) with only a 'name' attribute. Then I have the following rule: rule "test" when $cat:Cat( name == "tom" ) then $cat.setName("cat"); insertLogical(new String("test")); end When I test the rule against a Cat named tom, the logical inserted fact is not retracted. (So the fact is inserted because the rule matches, but is not retracted even if the rule is no more matching at the end.) If I change the order of the RHS, it works fine. The fact is inserted and then retracted. rule "test" when $cat:Cat( name == "tom" ) then insertLogical(new String("test")); $cat.setName("cat"); end So the behavior depends on the ordering of the RHS statements. Here is a complete example to show the problem: public class Cat { private String name; protected PropertyChangeSupport changes = new PropertyChangeSupport(this); public Cat(String name) { super(); this.name = name; } public String getName() { return this.name; } public void setName(String name) { final String oldName = this.name; this.name = name; this.changes.firePropertyChange("name", oldName, name); } public void addPropertyChangeListener(final PropertyChangeListener listener) { this.changes.addPropertyChangeListener(listener); } public void removePropertyChangeListener( final PropertyChangeListener listener) { this.changes.removePropertyChangeListener(listener); } } public class RHSOrderingTest { private static final String PACKAGE = "package ch.generali.pgr.rule "; private static final String IMPORT = "import ch.generali.pgr.rules.Cat "; private static final String WHEN = "rule \"test ok\" when $cat:Cat( name == \"tom\" ) "; private static final String THEN_OK = "then insertLogical(Integer.valueOf(1)); $cat.setName(\"cat\"); end"; private static final String THEN_KO = "then $cat.setName(\"cat\"); insertLogical(Integer.valueOf(1)); end"; private static final String RULE_OK = PACKAGE + IMPORT + WHEN + THEN_OK; private static final String RULE_KO = PACKAGE + IMPORT + WHEN + THEN_KO; private static final String QUERY = "query \"My test Integer\" integer : Integer( intValue == 1 ) end"; public static void main(String[] args) { boolean ok_1 = testWithRule(RULE_OK); boolean ok_2 = testWithRule(RULE_KO); System.out.println((ok_1 ? "SUCCESS: " : "FAILED: ") + THEN_OK); System.out.println((ok_2 ? "SUCCESS: " : "FAILED: ") + THEN_KO); } private static boolean testWithRule(String rule) { Cat tom = new Cat("tom"); RuleBase rb = createRuleBase(rule + "\n" + QUERY); WorkingMemory wm = rb.newStatefulSession(); wm.insert(tom, true); wm.fireAllRules(); QueryResults results = wm.getQueryResults("My test Integer"); return results.size() == 0; } private static RuleBase createRuleBase(String rules) { try { RuleBase ruleBase = RuleBaseFactory.newRuleBase(); PackageBuilderConfiguration conf = new PackageBuilderConfiguration(); PackageBuilder packageBuilder = new PackageBuilder(conf); Reader source = new StringReader(rules); packageBuilder.addPackageFromDrl(source); Package pkg = packageBuilder.getPackage(); ruleBase.addPackage(pkg); return ruleBase; } catch (Exception e) { throw new RuntimeException(e); } } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

7
24
0 / 0

[JBoss JIRA] (AS7-2694) OperationContext.isBooting() is returning false in domain mode boots

by Brian Stansberry (Created) (JIRA)

OperationContext.isBooting() is returning false in domain mode boots -------------------------------------------------------------------- Key: AS7-2694 URL: https://issues.jboss.org/browse/AS7-2694 Project: Application Server 7 Issue Type: Bug Components: Domain Management Reporter: Brian Stansberry Fix For: 7.1.0.CR1 OperationContext.isBooting() is returning false in domain mode boots. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
3
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 2012