July 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2180) CLONE -Default Guvnor repository path in Eclipse webdav plugin differs from Guvnors actual path.

by Neil Wallace (JIRA)

CLONE -Default Guvnor repository path in Eclipse webdav plugin differs from Guvnors actual path. ------------------------------------------------------------------------------------------------ Key: JBRULES-2180 URL: https://jira.jboss.org/jira/browse/JBRULES-2180 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-eclipse, drools-guvnor Affects Versions: 5.0.0.CR1 Environment: Windows XP SP3 with Sun JDK 1.5.0_15. Eclipse Version: 3.4.1 Build id: M20080911-1700. Note that the Guvnor was running under JBoss AS 4.2.2. Reporter: Neil Wallace Assignee: Kris Verlaenen Fix For: 5.0.1.FINAL This isn't really a bug, but more of a configuration issue. The default repository location displayed by the "Guvnor Repository Location" wizard in Eclipse is not the default location used by the Guvnor distributed under the drools project. Consequently, if you accept the default value in the wizard, it is likely you will not be able to connect to the repository running under the Guvnor. The default repository location in the wizard is: /jboss-brms/org.drools.guvnor.Guvnor/webdav However, the default location to connect to the drools Guvnor is: /drools-guvnor/org.drools.guvnor.Guvnor/webdav as the default URL for the Guvnor is: http://localhost:8080/drools-guvnor/org.drools.guvnor.Guvnor/Guvnor.html It is not obvious at first what is wrong, as if you accept the default repository location then the new location appears in the Guvnor Repositories view. But when you click on this repository name to browse it you get the following error: "Server not reachable" I initially assumed it was a network issue, or the wrong port (8080) etc. Only after careful inspection is it obvious that the default repository location in the Eclipse wizard does not match the default URL used by the drools Guvnor. There has been some discussion related to this under the JIRA GUVNOR-120, but I'm not sure if there is a conflict between the solution suggested in that JIRA and the issue raised here. To Reproduce Problem ============================ This assumes that the Guvnor is running locally at localhost:8080 which is the default location "out of the box". 1. Link to the Guvnor by selecting the menu option to run the "Guvnor Repository Location" wizard: File, New, Other, Guvnor, Guvnor Repository Location. 2. I accepted the defaults, adding only user and password: Location: localhost Port: 8080 Repository: /jboss-brms/org.drools.guvnor.Guvnor/webdav User Name: admin Password: admin Selected to save password Click Finish and the link is created successfully in the "Guvnor Repositories" view as: http://localhost:8080/jboss-brms/org.drools.guvnor.Guvnor/webdav 3. Click on the link above. This causes the following error: "Server not reachable" Notice that the URL for the link says jboss-brms instead of drools-guvnor. 4. Delete the link you just created and perform steps 1 and 2 again, but this time set the Repository value in step 2 as: /drools-guvnor/org.drools.guvnor.Guvnor/webdav 5. Click on the new link above. This should allow you to browse the repository on the Guvnor side correctly. -- 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

17 years

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2178) CLONE -Rule failes to compile in 5.0 March 20th SNAPSHOT. Compiles ok in 4.07

by Neil Wallace (JIRA)

CLONE -Rule failes to compile in 5.0 March 20th SNAPSHOT. Compiles ok in 4.07 ----------------------------------------------------------------------------- Key: JBRULES-2178 URL: https://jira.jboss.org/jira/browse/JBRULES-2178 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Environment: Win Xp sp3 Reporter: Neil Wallace Assignee: Edson Tirelli Fix For: 5.0.1.FINAL Attached code generates the following output. I would expect both rules to compile w/o an error. Start Fails Rule Compilation error : [Rule name='a.b'] test/Rule_a_b_0.java (11:488) : The method insert(Main) is undefined for the type Rule_a_b_0 Works Done -- 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

17 years

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2177) CLONE -NPE in compiler for fact class w/o getters/setters

by Neil Wallace (JIRA)

CLONE -NPE in compiler for fact class w/o getters/setters ---------------------------------------------------------- Key: JBRULES-2177 URL: https://jira.jboss.org/jira/browse/JBRULES-2177 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.0.0.CR1 Environment: any Reporter: Neil Wallace Assignee: Edson Tirelli Fix For: 5.0.1.FINAL A class with missing getters and setters, e.g.: public class Command { protected String ident; protected Code code; protected boolean refused; protected String reason; public Command( String id, Code c ){ ident = id; code = c; } } used in a rule pattern such as, e.g.: rule cleanupRefused when $c : Command( $i : ident, refused == true, $r : reason ) then # whatever end causes a NPE in Declaration:239 due to Declaration.readAccessor == null This should produce a compiler error message. NOTICE: Javadoc on constructors of class Declaration is incorrect! -- 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

17 years

1
0
0 / 0

[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

17 years

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

17 years

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

17 years

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

17 years

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

17 years

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

17 years

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

17 years

1
0
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 July 2009