January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8830) "Only one JAX-RS Application Class allowed.." on JBoss 6 final

by Viggo Navarsete (JIRA)

"Only one JAX-RS Application Class allowed.." on JBoss 6 final -------------------------------------------------------------- Key: JBAS-8830 URL: https://issues.jboss.org/browse/JBAS-8830 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Reporter: Viggo Navarsete See forum discussion for details. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

8
11
0 / 0

[JBoss JIRA] Created: (JBRULES-2533) Update Eclipse Compiler dependency

by Fabian Lange (JIRA)

Update Eclipse Compiler dependency ---------------------------------- Key: JBRULES-2533 URL: https://jira.jboss.org/browse/JBRULES-2533 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.1.0.M2 Reporter: Fabian Lange Assignee: Mark Proctor drools-compiler pom includes a reference to eclipse JDT. in 5.0.1 this was a 4 MB core_whatever.jar Because I wanted to improve compiler performance I tried out a never eclipse compiler package. Finding it was not very easy, because eclipse seems to change group and artifact ids every day. I found a module which only contains the compiler part from eclipse 3.5.1, which works in all my tests ok. Another nice benefit was that the size of my war shrunk by 3 Megabytes, as this module is only 1.7 megs. It even helped for performance of compilation process by the way. Not that this is a main bottleneck, but we have files that take seconds to compile. My tests on my windows box with java 6 gave 5-10% improvement using the 3.5.1 jdt compiler. Here the part for the pom: {code} <dependency> <groupId>org.eclipse.jdt.core.compiler</groupId> <artifactId>ecj</artifactId> <version>3.5.1</version> </dependency> {code} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2866) Support for Metadata in Decision Tables

by Jason Mihalick (JIRA)

Support for Metadata in Decision Tables --------------------------------------- Key: JBRULES-2866 URL: https://issues.jboss.org/browse/JBRULES-2866 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-decisiontables Affects Versions: 5.1.1.FINAL Environment: All Reporter: Jason Mihalick Assignee: Mark Proctor Fix For: FUTURE Please add support for Metadata annotations in decision tables. Discussion thread here: http://drools-java-rules-engine.46999.n3.nabble.com/Need-help-with-Decisi... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
11
0 / 0

[JBoss JIRA] Created: (JBAS-8470) SocketBinding.createMulticastSocket() not safe across platforms

by Brian Stansberry (JIRA)

SocketBinding.createMulticastSocket() not safe across platforms --------------------------------------------------------------- Key: JBAS-8470 URL: https://jira.jboss.org/browse/JBAS-8470 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brian Stansberry Fix For: 7.0.0.M2 The usage of java.net.MulticastSocket is one of the areas where the JDK does a poor job of abstracting away the underlying OS. Patterns of MulticastSocket construction that work well on BSD-based OSs don't work on Windows and vice versa. SocketBinding.createMulticastSocket() should adapt the code used in JGroups for dealing with this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
8
0 / 0

[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

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

7
24
0 / 0

[JBoss JIRA] Created: (JBRULES-2685) Performance degradation from 5.0.1 to 5.1.0

by Greg Barton (JIRA)

Performance degradation from 5.0.1 to 5.1.0 ------------------------------------------- Key: JBRULES-2685 URL: https://jira.jboss.org/browse/JBRULES-2685 Project: Drools Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.0.FINAL Environment: OSX 1.6.2 Reporter: Greg Barton Assignee: Mark Proctor Priority: Minor Attachments: DroolsNested.tar.gz I've observed a sizable (25%) performance degradation between the 5.0.1 and 5.1.0 releases. I've attached a sample project that tests the performance of matching nested objects. (ANd compares direct reference matching and the performance pitfalls of "from," but that's beside the current point.) If you switch the pom.xml from using 5.0.1 to 5.1.0 for the drools dependencies you'll see 25% longer execution times on the tests. (mvn test) Here's the test output: 5.0.1 reference.drl Count: 2000 reference.drl Time: 267ms reference.drl Time per element: 0.1335ms BAR Duplicates: 780 FOO Duplicates: 880 reference.drl Count: 20000 reference.drl Time: 1249ms reference.drl Time per element: 0.06245ms BAR Duplicates: 7702 FOO Duplicates: 8040 from.drl Count: 200 from.drl Time: 1139ms from.drl Time per element: 5.695ms BAR Duplicates: 112 FOO Duplicates: 102 reference.drl Count: 200 reference.drl Time: 5ms reference.drl Time per element: 0.025ms BAR Duplicates: 86 FOO Duplicates: 60 5.1.0 reference.drl Count: 2000 reference.drl Time: 300ms reference.drl Time per element: 0.15ms BAR Duplicates: 788 FOO Duplicates: 820 reference.drl Count: 20000 reference.drl Time: 1564ms reference.drl Time per element: 0.0782ms BAR Duplicates: 8142 FOO Duplicates: 7960 from.drl Count: 200 from.drl Time: 3543ms from.drl Time per element: 17.715ms BAR Duplicates: 68 FOO Duplicates: 90 reference.drl Count: 200 reference.drl Time: 13ms reference.drl Time per element: 0.065ms BAR Duplicates: 84 FOO Duplicates: 74 On the most taxing test (20k objects) 5.0.1 took 1249ms while 5.1.0 took 1564ms, and for larger tests the effect is more pronounced. This is primarily a test of == on object references. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

5
23
0 / 0

[JBoss JIRA] Created: (JBRULES-2590) Maven build fails in Linux with LANG=fr_FR.utf8

by Jean-Marc Vanel (JIRA)

Maven build fails in Linux with LANG=fr_FR.utf8 ------------------------------------------------ Key: JBRULES-2590 URL: https://jira.jboss.org/browse/JBRULES-2590 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Environment: % uname -a Linux jmv-desktop 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 2010 x86_64 GNU/Linux % java -version java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Reporter: Jean-Marc Vanel Assignee: Mark Proctor With sources from Subversion, making a Maven build on drools-trunk gives 3 errors : Tests in error: testDate(org.drools.base.FieldFactoryTest) testString(org.drools.base.mvel.MVELCalendarCoercionTest) testString(org.drools.base.mvel.MVELDateCoercionTest) Tests run: 578, Failures: 0, Errors: 3, Skipped: 1 [ERROR] BUILD FAILURE However this runs fine: LANG=en mvn install -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2298) Can't use functions when MVEL dialect is set at package level

by Michael Neale (JIRA)

Can't use functions when MVEL dialect is set at package level ------------------------------------------------------------- Key: JBRULES-2298 URL: https://jira.jboss.org/jira/browse/JBRULES-2298 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.1.FINAL Reporter: Michael Neale Assignee: Edson Tirelli Priority: Critical package jboss.cloud dialect "mvel" #trying to get functions working... rule "something" when s: SimpleFact(id == 42, name == "michael") then System.out.println("hello"); end function String doSomething() { return "hey"; } And I get: java.lang.NullPointerException at org.drools.rule.builder.dialect.mvel.MVELDialect.compile(MVELDialect.java:510) at org.drools.rule.builder.dialect.mvel.MVELDialect.addFunction(MVELDialect.java:338) at org.drools.compiler.PackageBuilder.addFunction(PackageBuilder.java:1104) at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:626) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:290) at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:488) at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:25) -- 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

6
8
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 2011