July 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2176) CLONE -multibyte characters in dsl fails with "no viable alternative at character"

by Neil Wallace (JIRA)

CLONE -multibyte characters in dsl fails with "no viable alternative at character" ----------------------------------------------------------------------------------- Key: JBRULES-2176 URL: https://jira.jboss.org/jira/browse/JBRULES-2176 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler-DSL Affects Versions: 5.0.0.M1, 5.0.0.M2, 5.0.0.M3, 5.0.0.M4, 5.0.0.M5, 5.0.0.CR1 Environment: Drools 5.0.0.CR1 Reporter: Neil Wallace Assignee: Edson Tirelli Fix For: 5.0.1.FINAL Drools compiler fails to compile DSLs containing multibyte characters in them, says "no viable alternative at character". ---------- line 3:6 no viable alternative at character '?' line 3:7 no viable alternative at character '?' java.lang.NullPointerException at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:451) at org.drools.reteoo.ReteooRuleBase.addPackage(ReteooRuleBase.java:481) at org.drools.compiler.MultibyteDSLTest.testMultibyteDSL(MultibyteDSLTest.java:20) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) ---------- http://lists.jboss.org/pipermail/rules-users/2009-March/008293.html -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2175) CLONE -Using the "from" syntax in the when clause when running the "Drools Application" in debug mode takes longer than normal.

by Neil Wallace (JIRA)

CLONE -Using the "from" syntax in the when clause when running the "Drools Application" in debug mode takes longer than normal. -------------------------------------------------------------------------------------------------------------------------------- Key: JBRULES-2175 URL: https://jira.jboss.org/jira/browse/JBRULES-2175 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-eclipse Reporter: Neil Wallace Assignee: Mark Proctor Fix For: 5.0.1.FINAL Just adding "t : Object() from m.getClass" to the drools project created by eclipse causes "builder.addPackageFromDrl( source );" to take about 48 seconds. if the from clause is not there it takes about 4 seconds. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2174) CLONE -DRL-Viewer does not keep position if refocused

by Neil Wallace (JIRA)

CLONE -DRL-Viewer does not keep position if refocused ----------------------------------------------------- Key: JBRULES-2174 URL: https://jira.jboss.org/jira/browse/JBRULES-2174 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-eclipse Affects Versions: 5.0.0.CR1 Environment: jre6u12 eclipse 3.4 Reporter: Neil Wallace Assignee: Kris Verlaenen Priority: Minor Fix For: 5.0.1.FINAL Using eclispe and working with an DSLR-File that depends an DSL-file. The DSLR-File is a FormEditor (Multiparteditor) with 2 tabs: first tab for editing, 2nd one the "DRL Viewer". Each time you navigate away and refocus that "DRL Viewer"-tab once again (with mouseclick) that view repositions the text to top / line 1. That's very annoying if you have a bigger rulefile (that's the normal case) in is not state of the art (therefore I think this is a bug and not a feature request). The viewer should keep it's position. Suggestion: only change to top of text if viewer-content is regenerated / changed. -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2173) CLONE -Line break in DSL isnot generated anymore since Drools 5.0.0 CR1

by Neil Wallace (JIRA)

CLONE -Line break in DSL isnot generated anymore since Drools 5.0.0 CR1 ----------------------------------------------------------------------- Key: JBRULES-2173 URL: https://jira.jboss.org/jira/browse/JBRULES-2173 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.0.0.CR1 Environment: jre6u12 eclipse 3.4 win xp Reporter: Neil Wallace Assignee: Edson Tirelli Fix For: 5.0.1.FINAL In Drools 4.0.7 and 5.0.0M5 it was possible to generate linebreaks using \n in an dsl-File. Since 5.0.0 CR1 this is no longer possible: the \n is simply converted to the letter n which leads to compile-errors concerning the replaced code. Example DSL: # Test linebreak-bug since 5.0.0 CR1 [*][]only a simple test = System.out.println \n ("Did it generate a line break?"); Example DSLR: #created on: 12.03.2009 package linebreak expander linebreakbug.dsl rule "line break bugtest" when #conditions then only a simple test end This leads to the line System.out.println n ("Did it generate a line break?"); Maybe this bug is related to https://jira.jboss.org/jira/browse/JBRULES-1970 where the handling of #-Characters in DSL-Files had been fixed. In my special case I'v got an workaround, but that's no workaround for anyone: Using one DSLR I generate 2 Outputs: a) using DSLR with dsl-file-A leads to "DLR"-Code: I don't need line breaks here (today, but maybe next month?) I don't care if the generated Code is nice or not and if the line is long or not. The code works and is executed by the rules-engine. Everything fine here. b) using DSLR with dsl-file-B leads to programming-code in another programming-language. This Code is never executed in Drools, it is simply generated. The result is taken an copied into the target-system. For that task I have written an own plugin that does that stuff and works like a little post-processor. So my workaround is to use my own "keyword" $CRLF in an DSL-File and - after the generation that Drools does - replaced that with "\n". Not where nice but simple... -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2172) CLONE -DSL can't support Chinese characters problem

by Neil Wallace (JIRA)

CLONE -DSL can't support Chinese characters problem ---------------------------------------------------- Key: JBRULES-2172 URL: https://jira.jboss.org/jira/browse/JBRULES-2172 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: All Reporter: Neil Wallace Assignee: Edson Tirelli Fix For: 5.0.1.FINAL I from Shanghai China. My Drools version is Drools5 M5. I get some errors from Drools ide when I use Chinese characters in dsl file and use it in dslr file. I think support Chinese characters is very important,so i hope drools team can fix this bug in next Drools version. Thanks. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2171) CLONE -No access to context in a constraint

by Neil Wallace (JIRA)

CLONE -No access to context in a constraint ------------------------------------------- Key: JBRULES-2171 URL: https://jira.jboss.org/jira/browse/JBRULES-2171 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.0.0.M5 Reporter: Neil Wallace Assignee: Kris Verlaenen Fix For: 5.0.1.FINAL Say I have a class Job with a method isFinished() that returns boolean. Also in a process context, I have a variable "job" of the type "Job". In a constraint on a split node, the following happens: a) When the constraint is in mvel dialect, the code "((Job)job).finished" is correct. b) When the constraint is in Java dialect, the code "Job j = (Job)(context.getVariable("job"));" gets me the following compilation error: Process Compilation error : org.drools.lang.descr.ProcessDescr@48f675 [omitted] (27:1248) : context cannot be resolved The documentation of this is quite clear: "Code constraints are expressions that return a boolean value. They have access to the context variable. MVEL code constraints also have direct access to the variables." Therefore I think this is a bug. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2170) CLONE -Code completion in DSL in when-part does not work properly anymore

by Neil Wallace (JIRA)

CLONE -Code completion in DSL in when-part does not work properly anymore ------------------------------------------------------------------------- Key: JBRULES-2170 URL: https://jira.jboss.org/jira/browse/JBRULES-2170 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-eclipse Affects Versions: 5.0.0.M5 Environment: Eclipse 3.4, JRE 6u10, WinXP Reporter: Neil Wallace Assignee: Kris Verlaenen Fix For: 5.0.1.FINAL When using the Code completion in an DSL-File-Editor in the when-part the completion does not work properly anymore. It only shows up if you hit ALT-Space and have no character entered, so you can see the full list of "commands". But it's not possible to restrict that list using the beginning of a phrase. In the then-part everything works find. And it already worked in "when" using Drools 4.0.7 with Eclipse 3.3. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2169) CLONE -issue with using contains operator on array or collection of double (any )

by Neil Wallace (JIRA)

CLONE -issue with using contains operator on array or collection of double (any ) --------------------------------------------------------------------------------- Key: JBRULES-2169 URL: https://jira.jboss.org/jira/browse/JBRULES-2169 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 4.0.7, 5.0.0.M3 Environment: Windows XP service pack2 Reporter: Neil Wallace Assignee: Mark Proctor Fix For: 5.0.1.FINAL When using 'contains' operator on array or collection of strings its working fine. But when we use it for an array of primitive type double it gives a classcastexception . Is auto boxing not supported? May be this is fine as it mentioned in the documentation that it works only on Objects. I tried using the array of Double objects, here it doesn't throw an excpetion but the rule wasn't firing. The behaviour was same even if I use a collection of Double objects. ex: using Array rule "OrderArray" when Order(valueArray contains 0) then System.out.println("OrderArray"); end. using Collection rule "OrderList" when Order(valueList contains 0) then System.out.println("OrderList"); end. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2168) CLONE -Deserializing a KnowledgeBase object throws a java.io.EOFException

by Neil Wallace (JIRA)

CLONE -Deserializing a KnowledgeBase object throws a java.io.EOFException ------------------------------------------------------------------------- Key: JBRULES-2168 URL: https://jira.jboss.org/jira/browse/JBRULES-2168 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.0.M4, 5.0.0.M5 Environment: Ubuntu 8.10 Reporter: Neil Wallace Assignee: Edson Tirelli Fix For: 5.0.1.FINAL A java.io.EOFException is thrown when reading a serialized KnowledgeBase object from a file. java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280) at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:55) at org.drools.common.DroolsObjectInputStream.<init>(DroolsObjectInputStream.java:49) at org.drools.common.AbstractRuleBase.readExternal(AbstractRuleBase.java:227) at org.drools.reteoo.ReteooRuleBase.readExternal(ReteooRuleBase.java:173) at org.drools.impl.KnowledgeBaseImpl.readExternal(KnowledgeBaseImpl.java:83) at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1792) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1751) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at com.sample.DroolsTest.read(DroolsTest.java:75) at com.sample.DroolsTest.testIO(DroolsTest.java:50) at com.sample.DroolsTest.main(DroolsTest.java:40) -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2167) CLONE -Deadlock when RuleAgent thread refreshes rules while another thread creates a statefulSession

by Neil Wallace (JIRA)

CLONE -Deadlock when RuleAgent thread refreshes rules while another thread creates a statefulSession ---------------------------------------------------------------------------------------------------- Key: JBRULES-2167 URL: https://jira.jboss.org/jira/browse/JBRULES-2167 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 4.0.7 Environment: Windows XP SP3 Sun JRE 1.5.0_14 Reporter: Neil Wallace Assignee: Mark Proctor Fix For: 5.0.1.FINAL I believe I have discovered a deadlock that can occur in drools 4.0.7 if the RuleAgent refreshes its associated RuleBase whilst a new stateful session is being created on the RuleBase by another thread. The thread dump below shows the deadlock where the two thread "Timer-15" and "DataSource(com.acme.Source)-2" are deadlocked. Thread "Timer-15" is the timer thread created by the RuleAgent rule refresh mechanism to check if the rules files have changed, and to refresh the rules when a change is found. If it finds changes to the rules then it obtains a lock (<0x189a8d88> (a java.util.HashMap)) and proceeds to removes the old version of the changed package from the RuleBase. To do this it needs to obtain another lock (<0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase)) before it can call removeRule. However, in another thread "DataSource(com.acme.Source)-2" a new stateful session is being created on the same RuleBase. This has already obtained the lock (<0x189a8d88> (a java.util.HashMap)) that the Timer thread is waiting for, and is itself waiting for the another lock <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase) that the Timer thread has already locked, hence the deadlock. In my own application I coded around this by eventually not using the RuleAgent in-built refresh mechanism, but instead periodically calling refreshRuleBase() on the RuleAgent in the SAME thread used to create the Stateful session, thus avoiding any deadlock. "Timer-15" daemon prio=6 tid=0x02f4b0e8 nid=0x1864 waiting for monitor entry [0x038cf000..0x038cfa68] at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:270) - waiting to lock <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase) at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:656) at org.drools.common.AbstractRuleBase.removePackage(AbstractRuleBase.java:570) - locked <0x189a8d88> (a java.util.HashMap) at org.drools.agent.PackageProvider.removePackage(PackageProvider.java:45) at org.drools.agent.PackageProvider.applyChanges(PackageProvider.java:63) at org.drools.agent.RuleAgent.refreshRuleBase(RuleAgent.java:320) at org.drools.agent.RuleAgent$2.run(RuleAgent.java:438) at java.util.TimerThread.mainLoop(Unknown Source) at java.util.TimerThread.run(Unknown Source) "DataSource(com.acme.Source)-2" daemon prio=4 tid=0x03027610 nid=0xfac waiting for monitor entry [0x0378f000..0x0378fb68] at org.drools.reteoo.ReteooRuleBase.newStatefulSession(ReteooRuleBase.java:225) - waiting to lock <0x189a8d88> (a java.util.HashMap) - locked <0x189a2ba0> (a org.drools.reteoo.ReteooRuleBase) at org.drools.common.AbstractRuleBase.newStatefulSession(AbstractRuleBase.java:284) at com.acme.RunRules.flush(RunRules.java:3337) at com.acme.ControlThread.run(ControlThread.java:465) at java.lang.Thread.run(Unknown Source) -- 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, 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 July 2009