[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
[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
[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
[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