July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Assigned: (JBRULES-261) Mismatched types in field constraints

by Edson Tirelli (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-261?page=all ] Edson Tirelli reassigned JBRULES-261: ------------------------------------- Assignee: Edson Tirelli (was: Mark Proctor) > Mismatched types in field constraints > ------------------------------------- > > Key: JBRULES-261 > URL: http://jira.jboss.com/jira/browse/JBRULES-261 > Project: JBoss Rules > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Rule Assemply/SPI > Affects Versions: 3.0.1 > Reporter: Michael Neale > Assigned To: Edson Tirelli > Priority: Minor > Fix For: 4.0.0.MR4 > > > Problem: If a rule compares two fields and one of them is a char and the > other one is a String, the match is always negative. No type-mismatch error > or warning is displayed. This can be quite confusing. The attached Eclipse > project illustrates this problem. > Suggested Solution: If all information is available at compile-time an error > should be generated on type mismatches. Otherwise there should be a warning > during run-time and maybe a type conversion attempt. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-573) EqualityAssertMapComparator does not work with JSR94 Fact Handles

by Juergen none (JIRA)

EqualityAssertMapComparator does not work with JSR94 Fact Handles ----------------------------------------------------------------- Key: JBRULES-573 URL: http://jira.jboss.com/jira/browse/JBRULES-573 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 3.0.5 Environment: java 1.5.0_09 Reporter: Juergen none Assigned To: Mark Proctor Equal objects are asserted multiple times via jsr94 interface Using jsr94 interface to use drools stateful rule session Assert behaviour set to equality: PROPERTY_ASSERT_BEHAVIOR = RuleBaseConfiguration.WM_BEHAVIOR_EQUALITY fact handle factory creates org.drools.jsr94.rules.Jsr94FactHandle objects BUT: org.drools.common.EqualityAssertMapComparator::hashCodeOf() obj.getClass() == this.factHandleClass is false because this.factHandleClass is DefaultFactHandle and obj.getClass() is Jsr94FactHandle --> so instead of hashcode of object wrapped by handle, hashcode of facthandle object is used --> equal objects are asserted multiple times GUESS: either - obj.getClass() instanceof this.factHandleClass or - this.factHandleClass should be set to Jsr94FactHandle? -- 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

17 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-970) filter of results from a "from" ce not working

by Edgardo Carena (JIRA)

filter of results from a "from" ce not working ---------------------------------------------- Key: JBRULES-970 URL: http://jira.jboss.com/jira/browse/JBRULES-970 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Rule Flow Affects Versions: 4.0.0.MR3 Reporter: Edgardo Carena Assigned To: Mark Proctor Priority: Critical whwn I use a statement like this $vendor : VendorDatabaseItem ( PIVA=="01255720169" ) from vendors.list; it works, filtering the list "vendor.list" by taking only the items with $vendor.getPIVA equal to "01255720169". however if I do something like $piva : "01255720169"; $vendor : VendorDatabaseItem ( PIVA==$piva ) from vendors.list; the result is different, and $vendor will get all the values in the list, ignoring the filter. -- 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

17 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-458) NAKACK: REBROADCAST_MSGS blocks forever

by Bela Ban (JIRA)

NAKACK: REBROADCAST_MSGS blocks forever --------------------------------------- Key: JGRP-458 URL: http://jira.jboss.com/jira/browse/JGRP-458 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP1 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 If max_rebroadcast_timeout is high, then that event never returns. -- 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

17 years, 6 months

1
3
0 / 0

[JBoss JIRA] Commented: (JBPM-72) required variable declaration

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-72?page=comments#action_12367825 ] Ronald van Kuijk commented on JBPM-72: -------------------------------------- 1: <variable name="bla" type="string" /> would only have runtime checking , as would 2: <variable name="bla" type="string" value="blaValue"/> What we could do is something like 3: <variable name="bla"> <string>a string</string> </variable> and have elements for all default supported types. This can be checked design-time as long as there are corresponding XSD types. One other option is to extend the eclipse xml validator and make it aware of format #2 and check those... 3 would imo have the least impact > required variable declaration > ----------------------------- > > Key: JBPM-72 > URL: http://jira.jboss.com/jira/browse/JBPM-72 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Priority: Optional > > we could add support for a configuration that requires all variables to be declared (including the type) before they are used. this creates a bit of 'type safety', although it is only checkable at runtime... > this should be done on the level of the task. maybe tasks should be able to extract data from the process and completion of the task should update the variables in the context. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBPM-228) Allow <variable> to have "any" content for user metadata

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-228?page=all ] Ronald van Kuijk closed JBPM-228. --------------------------------- Fix Version/s: jBPM jPDL 3.2 jBPM 3.1 Resolution: Done This is already possible in 3.1 and 3.2. The thing is it is not persisted in the DB, but the complete PD is persisted in the DB as XML. Retrieving these custom attributes is being worked on for 3.3 (maybe 3.2.2). I only want to change the '##any' to '##other' > Allow <variable> to have "any" content for user metadata > -------------------------------------------------------- > > Key: JBPM-228 > URL: http://jira.jboss.com/jira/browse/JBPM-228 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Affects Versions: jBPM 3.0 beta 2 > Environment: All > Reporter: Jim Rigsbee > Assigned To: Tom Baeyens > Priority: Minor > Fix For: jBPM jPDL 3.2, jBPM 3.1 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Please allow the <variable> element allow "any" schema content just like the "handlers". This would allow the user to store custom metadata for their purposes. This data should be persisted to the database and the API should allow its retrieval just like <action>, <assignment>, and <decision>/<handler>, etc. > We intend on using this to assist with driving the user interface from the work flow engine. One type of meta data we need is the "java type" for the variable. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBPM-613) Improve variable support

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-613?page=comments#action_12367822 ] Ronald van Kuijk commented on JBPM-613: --------------------------------------- This should either also include a type like <variable name="documentType" access="read" value="RTF" type="String"/> OR a different format like <variable name="documentType" access="read"> new String("RTF"); </variable> in bsh format or something like that. > Improve variable support > ------------------------ > > Key: JBPM-613 > URL: http://jira.jboss.com/jira/browse/JBPM-613 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: J.Enrique Ruiz > Assigned To: Tom Baeyens > Priority: Minor > > Hi, > The JPDL variable element can be used to share info with a new process instance created in a process-state. Sometimes, it is interesting to set the value of a variable in the JPDL, for example: > <process-state name="cms"> > ... > <variable name="documentType" access="read" value="RTF" /> > ... > </process-state> > Currently, we have a ActionHandler that has been defined in the node-enter event. This ActionHandler puts the values in the variable map of the parent process instance, but the new feature can simplify it. > Best regards. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-66) add collections support to process variables

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-66?page=all ] Ronald van Kuijk updated JBPM-66: --------------------------------- Fix Version/s: jBPM 3.3 > add collections support to process variables > -------------------------------------------- > > Key: JBPM-66 > URL: http://jira.jboss.com/jira/browse/JBPM-66 > Project: JBoss jBPM > Issue Type: Feature Request > Components: Core Engine > Reporter: Tom Baeyens > Assigned To: Tom Baeyens > Priority: Optional > Fix For: jBPM 3.3 > > > we can add support for collections and maps to process variables. > even a merge can be implemented straightforward when the collections are updated. > this would require a ListVariableInstance and a MapVariableInstance.... -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBPM-672) more examples to explain how to use a non default TaskController.

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-672?page=all ] Ronald van Kuijk updated JBPM-672: ---------------------------------- Summary: more examples to explain how to use a non default TaskController. (was: more examples to explain how to use a non default Action Controller.) > more examples to explain how to use a non default TaskController. > ----------------------------------------------------------------- > > Key: JBPM-672 > URL: http://jira.jboss.com/jira/browse/JBPM-672 > Project: JBoss jBPM > Issue Type: Task > Components: Documentation > Reporter: Rodrigo Rezende > Assigned To: Tom Baeyens > Priority: Minor > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The documentation don't explain very well how to use another Action Controllers... Ther is no examples on documentation. -- 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

17 years, 6 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBPM-517) Problem with published 3.0 schema (http://jbpm.org/xsd/jpdl-3.0.xsd)

by Ronald van Kuijk (JIRA)

[ http://jira.jboss.com/jira/browse/JBPM-517?page=all ] Ronald van Kuijk closed JBPM-517. --------------------------------- Resolution: Out of Date 3.0 is in hibernation, these kinds of things will not be fixed anymore > Problem with published 3.0 schema (http://jbpm.org/xsd/jpdl-3.0.xsd) > -------------------------------------------------------------------- > > Key: JBPM-517 > URL: http://jira.jboss.com/jira/browse/JBPM-517 > Project: JBoss jBPM > Issue Type: Bug > Components: Core Engine > Affects Versions: jBPM 3.0 > Reporter: Andy Morris > Assigned To: Tom Baeyens > Priority: Minor > > The end-tasks attribute on the task-node element in the published schema (i.e. http://jbpm.org/xsd/jpdl-3.0.xsd) is an invalid attribute within the 3.0 codebase. > It is a new feature added to 3.1 > The published schema needs ammending. -- 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

17 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2007