July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-141) Create a generic HA Singleton API

by Brian Stansberry (JIRA)

Create a generic HA Singleton API --------------------------------- Key: JBCLUSTER-141 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-141 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Also want to extract the HASingletonElectionPolicy code from the AS codebase. -- 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

13 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-1699) BRMS: Cannot easily remove data when creating a test scenario

by Jaroslaw Kijanowski (JIRA)

BRMS: Cannot easily remove data when creating a test scenario ------------------------------------------------------------- Key: JBRULES-1699 URL: https://jira.jboss.org/jira/browse/JBRULES-1699 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.0.0.M1 Reporter: Jaroslaw Kijanowski Assignee: Michael Neale Fix For: 5.0.0.M2 I create a test scenario and add a fact in the Given section. If I want to remove it, I have to add a field. Then two "minus" signs appear, on for the field and one for the whole fact. Same for the Expect section and globals. -- 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

13 years, 6 months

5
12
0 / 0

[JBoss JIRA] Created: (JBRULES-1135) Move generation should be described in a drl

by Geoffrey De Smet (JIRA)

Move generation should be described in a drl -------------------------------------------- Key: JBRULES-1135 URL: http://jira.jboss.com/jira/browse/JBRULES-1135 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Affects Versions: 4.0.0.GA Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Fix For: FUTURE instead of MoveFactory POJO -- 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

13 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JGRP-403) Refactoring of MessageDispatcher, RpcDispatcher, RequestCorrelator and GroupRequest

by Bela Ban (JIRA)

Refactoring of MessageDispatcher, RpcDispatcher, RequestCorrelator and GroupRequest ----------------------------------------------------------------------------------- Key: JGRP-403 URL: http://jira.jboss.com/jira/browse/JGRP-403 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 3.0 We may be able to trash GroupRequest and RequestCorrelator, this functionality can be provided by MessageDispatcher -- 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

13 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1232) [solver] Selector refactor: configurable subset selections, topList usage etc

by Geoffrey De Smet (JIRA)

[solver] Selector refactor: configurable subset selections, topList usage etc ----------------------------------------------------------------------------- Key: JBRULES-1232 URL: http://jira.jboss.com/jira/browse/JBRULES-1232 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Currently all moves are evaluated at every step (with a MaxAllForager at least) if you use the basic cached move factory selector. This doesn't scale well, especially for big data problems where in the beginning, just about every moves improves. The neighbourhood size (= amount of selected moves) could for example increase block-wise or timeGradient-wise until an improving solution is found. Notice the difference with the usage of FirstImprovingForager. -- 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

13 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1457) please support containment test for map keys

by Godmar Back (JIRA)

please support containment test for map keys -------------------------------------------- Key: JBRULES-1457 URL: http://jira.jboss.com/jira/browse/JBRULES-1457 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.4 Environment: any Reporter: Godmar Back Using MVEL as the language for clauses, there is no way to test whether a map's key contain a value. For instance: rule "number 1" when e : S(map.keySet() contains "x") then System.out.println("rule number 1"); end leads to a syntax error because Drool's parser does not allow function calls ("keySet())" in clauses. On the other hand, MVEL (according to Mike Brocks, please read http://jira.codehaus.org/browse/MVEL-53 ) does not provide an operator to test containment in a map's set (or values). He said he's considering adding a shortcut such as .keys and .values in 2.0 and recommended I open a Drools JIRA issue. Please provide a way to test for membership in a map's key and value set. -- 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

13 years, 7 months

4
14
0 / 0

[JBoss JIRA] Created: (JBRULES-540) Create a Java Interface to allow JavaBeans to work more seamlessly as Facts

by Mark Proctor (JIRA)

Create a Java Interface to allow JavaBeans to work more seamlessly as Facts ----------------------------------------------------------------------------- Key: JBRULES-540 URL: http://jira.jboss.com/jira/browse/JBRULES-540 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 We want to move management of the bean and its working memory up a layer. When a bean is instantiated by an IoC framework it should weave in an interface to provide better background interoprability between the bean and working memories. further the IoC container should control the life cycle, assert and retract, of that bean in various working memories. -- 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

13 years, 7 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1430) Improve Function feature

by longDuck dong (JIRA)

Improve Function feature ------------------------ Key: JBRULES-1430 URL: http://jira.jboss.com/jira/browse/JBRULES-1430 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Affects Versions: 4.0.4 Environment: all Reporter: longDuck dong Priority: Minor The current design of the Function is a bit limiting. for example, if I want to write a function to insert, update or retract facts, the current design does not support it. According to the docs http://downloads.jboss.com/drools/docs/4.0.4.17825.GA/html/ch06s04.html, functions are just helper methods. It would be more powerful if the function always passes the workingmemory to the function. This way, the functions can easily access the globals or access the rule engine. Basically, something similar to JESS funcall http://herzberg.ca.sandia.gov/docs/70/api/jess/Funcall.html. It also makes it easier for developers to encapsulate common actions in the consequence in a function and use it easily from a DSL. The pattern is well proven in CLIPS, JESS and haley. -- 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

13 years, 7 months

3
10
0 / 0

[JBoss JIRA] Created: (JBRULES-1559) Ability to negate a constraint group

by Dirk Bergstrom (JIRA)

Ability to negate a constraint group ------------------------------------ Key: JBRULES-1559 URL: http://jira.jboss.com/jira/browse/JBRULES-1559 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: FUTURE Reporter: Dirk Bergstrom Assigned To: Mark Proctor Priority: Minor I want to write a rule that says "Find all long-eared dogs that do not have short, black hair". This seems like the simple way to do it: collect( Dog( ears=="long", not (hair=="short" && color=="black") ) But that doesn't parse. Some digging through the archives unearthed a mention of De Morgan's laws, which leads to: http://en.wikipedia.org/wiki/De_Morgan's_laws Which explains that I can instead write: collect( Dog( ears=="long", (hair!="short" || color!="black") ) Which, after some mental effort, turns out to be the right thing. However, had I not found the reference to De Morgan's Law, it would have taken me a long time to get there (if indeed I ever would have). The end result is also quite difficult to parse if you're not a logician, and thus not very user-friendly. -- 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

13 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1662) Tomcat Debugging of Rules

by Paul Ryan (JIRA)

Tomcat Debugging of Rules ------------------------- Key: JBRULES-1662 URL: http://jira.jboss.com/jira/browse/JBRULES-1662 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Eclipse IDE Environment: Tomcat 5+ and Eclipse IDE Reporter: Paul Ryan Assigned To: Mark Proctor The ability to debug rules while running from a tomcat instance. This would be helpful for those of us that have services wrapping the rules so that we can debug into running rule sets. This feature should be capable of running its own instance of tomcat as well as attaching to a debug version of an externally running tomcat to allow for flexibility based on the users socket needs. This feature would be a huge selling point for enterprise applications of Drools. -- 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

13 years, 7 months

2
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 2008