July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPM-999) Investigate and disable SF CVS

by Ronald van Kuijk (JIRA)

Investigate and disable SF CVS ------------------------------ Key: JBPM-999 URL: http://jira.jboss.com/jira/browse/JBPM-999 Project: JBoss jBPM Issue Type: Task Reporter: Ronald van Kuijk Assigned To: Tom Baeyens Creates lots of confusion. Also post an item at the sf page that mentiones -- 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

16 years, 12 months

1
2
0 / 0

[JBoss JIRA] Commented: (JBPM-569) improve EL expression examples in the user guide

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-569?page=comments#action_12367815 ] Ronald van Kuijk commented on JBPM-569: --------------------------------------- Koen, Tom, I want to put this on my list, but either of you have to give a decisive answer regarding the condition. > improve EL expression examples in the user guide > ------------------------------------------------ > > Key: JBPM-569 > URL: http://jira.jboss.com/jira/browse/JBPM-569 > Project: JBoss jBPM > Issue Type: Task > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Koen Aers > Fix For: jBPM jPDL 3.2.2 > > -- 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

16 years, 12 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4521) TimerTaskImpl.run must log exception stack trace

by Carlo de Wolf (JIRA)

TimerTaskImpl.run must log exception stack trace ------------------------------------------------ Key: JBAS-4521 URL: http://jira.jboss.com/jira/browse/JBAS-4521 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.2.0.GA Reporter: Carlo de Wolf Currently only e.toString() is logged. The full stack trace must be logged. -- 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

16 years, 12 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-570) Problem compiling package from xml

by Javier Prieto (JIRA)

Problem compiling package from xml ---------------------------------- Key: JBRULES-570 URL: http://jira.jboss.com/jira/browse/JBRULES-570 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: xml Affects Versions: 3.0.4 Environment: Windows XP, Eclipse 3.2, JBoss Rules IDE 3.0.4 Reporter: Javier Prieto Assigned To: Mark Proctor There is a problem compiling package from an xml rule file with rules calling functions in the rhs body. This is an example of an xml rule file that fails: <?xml version="1.0" encoding="UTF-8"?> <package name="com.sample" xmlns="http://drools.org/drools-3.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance" xs:schemaLocation="http://drools.org/drools-3.0 drools-3.0.xsd"> <function return-type="void" name="manageAlert"> <parameter identifier="alert" type="String"/> <body>System.out.println(alert);</body> </function> <function return-type="void" name="manageRuleFired"> <parameter identifier="ruleName" type="String"/> <body>System.out.println(ruleName + " fired");</body> </function> <rule name="Impossible Rule"> <lhs> <eval>1 == 2</eval> </lhs> <rhs>manageAlert("impossibleRule!!!"); manageRuleFired("Impossible Rule");</rhs> </rule> </package> I've found a workaround. If you insert a blank char anywhere in the first sentence of the rhs body (manageAlert(...);), it works well: <rhs>manageAlert ("impossibleRule!!!"); manageRuleFired("Impossible Rule");</rhs> (blank after manageAlert) or, <rhs>manageAlert( "impossibleRule!!!"); manageRuleFired("Impossible Rule");</rhs> (blank after '(' ) or, <rhs> manageAlert("impossibleRule!!!"); manageRuleFired("Impossible Rule");</rhs> (blank at the begining) or, <rhs>manageAlert("impossible Rule!!!"); manageRuleFired("Impossible Rule");</rhs> (blank in the string) ... If you call a Java method just before or after 'manageAlert("impossible Rule!!!");' with a blank between them, it works well too: <rhs>System.out.println("Hello"); manageAlert("impossibleRule!!!"); manageRuleFired("Impossible Rule");</rhs> <rhs>manageAlert("impossibleRule!!!"); System.out.println("Hello"); manageRuleFired("Impossible Rule");</rhs> ... I attach a test case with the xml rule file that cause the rule compilation error and the main class to test it. -- 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

16 years, 12 months

4
5
0 / 0

[JBoss JIRA] Created: (JBRULES-553) Add newlines in parser error messages

by Dirk Bergstrom (JIRA)

Add newlines in parser error messages ------------------------------------- Key: JBRULES-553 URL: http://jira.jboss.com/jira/browse/JBRULES-553 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 3.0.4 Reporter: Dirk Bergstrom Assigned To: Mark Proctor Priority: Minor Some kinds of parser errors get strung together on a single very long line, which makes it irritating to debug problems. This doozy is 332 characters long: org.drools.rule.InvalidRulePackage: Rule Compilation error Class "net.juniper.dash.RUM" has no method named "countPicklistFieldsComparingxTo" Instance method "countPicklistFieldsComparingxTo" cannot be invoked in static context Exception:2 errors while compiling unit "net/juniper/dash/Rule_RLIs_with_missing_func_specs_0.java" That's a lot of side-scrolling to figure out what happened. Breaking it up into four or five lines would greatly increase readability. -- 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

16 years, 12 months

3
2
0 / 0

[JBoss JIRA] Closed: (JBRULES-264) Fine grained Meta-Data driven intelligent parser

by Mark Proctor (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-264?page=all ] Mark Proctor closed JBRULES-264. -------------------------------- Resolution: Out of Date Edson has re-worked the parser, while improvements can be made, this is no longer valid. > Fine grained Meta-Data driven intelligent parser > ------------------------------------------------ > > Key: JBRULES-264 > URL: http://jira.jboss.com/jira/browse/JBRULES-264 > Project: JBoss Rules > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Drl Parser/Builder > Reporter: Mark Proctor > Assigned To: Bob McWhirter > Fix For: 4.0.0.MR4 > > > Currently we use the same API to parse and compile packages as we do for the IDE. This is proving quite heavy. I propose that we make an additional API for IDE integration that is fine grained and meta data driven. I believe that Eclipse has extensive meta data capabilities, which it stores on disk, we should really try and leverage this. Although the core API should try and be independent, so other IDEs can leverage it. > 1) Split the main document up into package, imports, globals, functions and rules ? but do not parse contents. > a. Maybe we will build up the meta-data for imports and globals at this stage, as I imagine that?s easy. > b. Record, as meta data, the start and end line numbers, i.e. the range, for all sections. > > 2) Tokenise all expressions and blocks ? do not loose line numbers though, so will need to pad. > a. Record, as meta data, the start and end line/col numbers, i.e. the range, for all expressions and blocks. > > 3) Parse each Rule > a. Validate Conditional Element and Field Constraint structure > b. Validate Columns and Fields ? record this in meta data. So we know the dependant classes and fields for this rule. > c. Record Column and Field bindings as meta data ? as used for expressions. > d. Validate operators and the RHS value type, checks it?s valid with LHS and operator. > > 4) Determine required declarations for each expression and record as meta data > a. If we can it might be nice to also determine dependant classes from the Imports and Globals , beyond declarations, and record as meta data. > > 5) Compile each expression and block, using a helper util, record the errors as meta data and then forget the compiled .class > 6) Develop intelligent balanced-text recovery. So when scanning 1) and 2) we need to check for balanced text, if we detect incorrect balancing we then mark that section as invalid and find the start of the next valid section ? nothing inside those invalid sections will be parsed. > a. i.e. if we have an invalid expression, incorrect number of brackets on the LHS of the rule, we try and recover to the next valid area, ideally this would be the next valid conditional element ? but that may be hard and it could be the RHS of the rule. Start simple, make it coarse, and intelligent fine grained can be added later. > > 7) Intelligent re-parsing for project wide changes. > a. We have class dependencies in meta-data for the various sections ? and also fields in constraints. So we can determine errors from the meta data, without having to reparse. > b. In the case of expressions we can use the meta data, to avoid re-compiling. I guess if the changes are too dramatic then we can recompile the expression/consequence. We have the ranges in meta data for the dependant sections, so we can rescan to suck up the expression, without having to parse the entire document > c. In document editing we only recompile expressions consequence if the user edits them ? again we should know that we are in an expression, we know the start so we scan from the start of t he expression/block to the end and compile. Avoid reparse the entire document or even the rule. If bindings are changed we can also determine the dependant expressions and recompile to get errors. > > > I am sure there is a lot more complexity to this and missed stages. But it should be enough to show you the direction I want to take this. So we are extensively using meta data to minimise the re-parsing and re-compiling. We are also using meta data to localise the areas that we do need to re-parse for changes. The key to this is always being able to know exactly what we are editing. We may have to extend the descr, or create a new structure to handle meta data driven parsing. Non of this replaces the existing ruleparse/descry/packagebuidler implementations which are still required for compiling and deploying real rule bases - although hopefully we can leverage parts from both, to avoid duplication. -- 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

16 years, 12 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-501) DRL -> decision table (round trip)

by Scott Reed (JIRA)

DRL -> decision table (round trip) ---------------------------------- Key: JBRULES-501 URL: http://jira.jboss.com/jira/browse/JBRULES-501 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Decision tables Reporter: Scott Reed Assigned To: Mark Proctor It would be extremely useful to be able to convert existing rules to decision tables. The educational value alone would make it worth while, but it would speed up development as well since the DRL -> decision table mapping is not straight forward and cell merging and coloring is fairly tedious. Users would probably want to be able to select the rules and functions to be mapped. If so, then the results of the mapping would have to be one or more decision table files and a new DRL file containing the rules and functions that were not converted. -- 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

16 years, 12 months

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-949) the rules of decision table was looped.

by jiang jinfeng (JIRA)

the rules of decision table was looped. ----------------------------------------- Key: JBRULES-949 URL: http://jira.jboss.com/jira/browse/JBRULES-949 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Decision tables Affects Versions: 3.0.1 Environment: window xp, eclipse-3.1.2 Reporter: jiang jinfeng Assigned To: Mark Proctor There were some discussions about this issue in the drools-user mailing list already. In the decision table, salience = true: When I modify a variable in the action cell, even I have specified keyword "UNLOOP" to be true, all other rules satisfying the new conditions are fired (even for rules which already fired before). Therefore, the whole rule set is looped and can not stop running. Currently I need to set up a lot of flags to avoid this situation ... -- 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

16 years, 12 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-502) Add binding semantics for decision table authors

by Scott Reed (JIRA)

Add binding semantics for decision table authors ------------------------------------------------ Key: JBRULES-502 URL: http://jira.jboss.com/jira/browse/JBRULES-502 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Decision tables Reporter: Scott Reed Assigned To: Mark Proctor The expressive capability of decision tables for non-programmer authors is limited. Especially, the author has no way to tell the developer to use the value of a property from one column in the condition for another. I can think of two ways that binding semantics could be added: Use the comment cells (i.e. "Age: Person's Age") - this is simple and expressive but would cause problems if an author wants to use the '<word>:' construct in a comment without intending it to be a binding. Add a designated row above or below the comment row. -- 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

16 years, 12 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-906) Two or more function-definitions lead to "Function Compilation Error".

by Dr. Gernot Starke (JIRA)

Two or more function-definitions lead to "Function Compilation Error". ---------------------------------------------------------------------- Key: JBRULES-906 URL: http://jira.jboss.com/jira/browse/JBRULES-906 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.1-m1 Environment: Mac OS X, regardless of JDK version Reporter: Dr. Gernot Starke Assigned To: Mark Proctor Two or more function-definitions lead to "function compilation error". Seems to be fixed in 4.0 M2... too bad I cannot currently upgrade. -- 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

16 years, 12 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007