January 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2395) Events with @expire never expire unless they appear in a rule

by Barry Kaplan (JIRA)

Events with @expire never expire unless they appear in a rule ------------------------------------------------------------- Key: JBRULES-2395 URL: https://jira.jboss.org/jira/browse/JBRULES-2395 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (fusion) Environment: 5.1.0.SNAPSHOT as of submit date Reporter: Barry Kaplan Assignee: Mark Proctor Fix For: 5.1.0.M2 Attachments: events not in pattern do not expire.zip This is because if the event never appears in a pattern a ObjectTypeNode is never created and the WorkingMemoryReteExpireAction is never configured. -- 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

16 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2288) Investigate a possible problem when using forall() with sliding windows

by Edson Tirelli (JIRA)

Investigate a possible problem when using forall() with sliding windows ----------------------------------------------------------------------- Key: JBRULES-2288 URL: https://jira.jboss.org/jira/browse/JBRULES-2288 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler, drools-core Affects Versions: 5.0.1.FINAL, 5.1.0.M1 Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 5.1.0.M2 There is no much info on this, but Jeff reported some rules were not working when using "forall" with patterns with sliding windows and entry points. Ex: forall( EventX(...) over window:time(...) from entry-point Y ) Need to investigate, add some integration tests and ensure the scenario works fine. -- 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

16 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2393) Drools 5.1.0.M2 release

by Toni Rikkola (JIRA)

Drools 5.1.0.M2 release ----------------------- Key: JBRULES-2393 URL: https://jira.jboss.org/jira/browse/JBRULES-2393 Project: Drools Issue Type: Release Security Level: Public (Everyone can see) Components: All Reporter: Toni Rikkola Assignee: Toni Rikkola -- 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

16 years, 1 month

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2098) Internal TupleSink list is not properly cleaned up when removing rules from a RuleBase

by Christian NedregÃ¥rd (JIRA)

Internal TupleSink list is not properly cleaned up when removing rules from a RuleBase -------------------------------------------------------------------------------------- Key: JBRULES-2098 URL: https://jira.jboss.org/jira/browse/JBRULES-2098 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 4.0.7 Environment: Drools 4.0.7 Win XP Sun JDK 1.4.2_11 Reporter: Christian NedregÃ¥rd Assignee: Mark Proctor When a new rule is added to a rule base that has shareBetaNodes=true 'BuildUtils.attachNode' will iterate through existing TupleSink nodes and try to find an equal node to re-use. In our production code we are seing NoClassDefFoundErrors from 'EvalConditionNode.equals' in scenarios where rules are both removed from and added to a rule base. The NoClassDefFoundErrors occours when a rule has recently been removed from the rule base and we are trying to add a new rule. When BuildUtils.attachNode' iterates through the existing TupleSinks it also encounters TupleSinks that belongs to the rule that was removed. The call to the TupleSinks 'equal' method yields a NoClassDefFoundErrors because the target TupleSink are trying to reference the rule class that has been removed. In this scenario we have removed rule 10418 and are adding 11140: java.lang.NoClassDefFoundError: rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0 at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.class$(Unknown Source) at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_10418_0Eval0Invoker.getMethodBytecode(Unknown Source) at rules.subscriptiontype.Rule_RequiredSubscriptionTypes_11140_0Eval0Invoker.equals(Unknown Source) at org.drools.rule.EvalCondition.equals(EvalCondition.java:121) at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201) at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101) Attached is a stand-alone JUnit 4 testcase where the test 'testWithBetaNodeSharing' shows this problem. It does not produce a NoClassDefFoundError but we get a NPE from <removed rule>Eval0Invoker.getMethodBytecode instead (rule 1 has been removed, rule 3 is about to be added): java.lang.NullPointerException at failure_on_removal.Rule_rule_1_0Eval0Invoker.getMethodBytecode(Unknown Source) at failure_on_removal.Rule_rule_3_0Eval0Invoker.equals(Unknown Source) at org.drools.rule.EvalCondition.equals(EvalCondition.java:121) at org.drools.reteoo.EvalConditionNode.equals(EvalConditionNode.java:201) at org.drools.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:101) We intepret this to be a symptom of the same problem. The workaround is to disable beta node sharing wich will bypass the TupleSink iteration alltogheter. This is shown in the test 'testWithoutBetaNodeSharing'. Kind regards Christian Nedregård -- 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

16 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2353) Update HumanTask to the new grid inf and CommandExecutor

by Mark Proctor (JIRA)

Update HumanTask to the new grid inf and CommandExecutor -------------------------------------------------------- Key: JBRULES-2353 URL: https://jira.jboss.org/jira/browse/JBRULES-2353 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-process Reporter: Mark Proctor Assignee: Mauricio Salatino Fix For: 5.1.0.M2 -- 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

16 years, 1 month

4
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2097) Implementation for the BPM web-console

by Kris Verlaenen (JIRA)

Implementation for the BPM web-console -------------------------------------- Key: JBRULES-2097 URL: https://jira.jboss.org/jira/browse/JBRULES-2097 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kris Verlaenen Assignee: Kris Verlaenen Fix For: 5.1.0.M1 Provide a back-end implementation using Drools Flow for the BPM console by Heiko Braun. -- 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

16 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2349) Rename Drools Solver to Drools Planner

by Geoffrey De Smet (JIRA)

Rename Drools Solver to Drools Planner -------------------------------------- Key: JBRULES-2349 URL: https://jira.jboss.org/jira/browse/JBRULES-2349 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-solver Affects Versions: 5.1.0.M1 Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Fix For: 5.1.0.M2 see blog -- 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

16 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAOP-762) Permission Issue (with AOP) in Applet Environment

by Howard Gao (JIRA)

Permission Issue (with AOP) in Applet Environment ------------------------------------------------- Key: JBAOP-762 URL: https://jira.jboss.org/jira/browse/JBAOP-762 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.5.6.GA Reporter: Howard Gao Fix For: 1.5.7.GA Attachments: java_console.out Summary: JBM client packed in an Applet. The client gets "java.util.PropertyPermission legacyParsing read" AccessControlException when trying to create a JMS connection. Possible Reason: The AccessControlContext was changed after JBM going through some AOP stack. AOP version 1.5.6.GA To reproduce this issue, I did the following: 1. create a simple applet. The applet create a button "DoWork". 2. Pressing "DoWork" will cause the applet to do a jndi lookup for a connection factory and call creationConnection() on the factory. In createConnection(), there is a method call on an AOP instrumented object: createConnection() { ... String wok = aopObj.doSomeWork("GoodWook"); ... } The aopObj is a simple class with one method: public class FakeInvokerLocatorWithAOP implements Serializable { private static final long serialVersionUID = 2223089961647029627L; public String doSomeWork(String work) { return work + " done. : " + System.getProperty("legacyParsing"); } } This class has an advice defined in AOP xml : <aspect class="org.jboss.jms.client.container.SimpleAspect" scope="PER_VM"/> <bind pointcut="execution(* org.jboss.jms.client.delegate.FakeInvokerLocatorWithAOP->doSomeWork(..))"> <advice name="handleDoSomeWork" aspect="org.jboss.jms.client.container.SimpleAspect"/> </bind> The Advice class SimpleAspect is very simple: public class SimpleAspect { public Object handleDoSomeWork(Invocation inv) throws Throwable { String res = (String)inv.invokeNext(); res = res + " with AOP"; System.out.println("-----res: " + res); return res; } } So if the call of aopObj.doSomeWork("GoodWook") is successful, the returned value should be something like: "GoodWook done. " + <value of sys prop 'legacyParsing'> + " with AOP" But the real situation is that I got the following exception: java.security.AccessControlException: access denied (java.util.PropertyPermission legacyParsing read) Debugging shows that once the execution goes inside SimpleAspect.handleDoSomeWork(), the system's AccessControlContext has changed, but the SecurityManager remained same as before. This changed context doesn't allow the above permission. I also checked the SimpleAspect's ProtectionDomain by PermissionCollection pcol = this.getClass().getProtectionDomain().getPermissions(); And this proctection domain's permissions implies the above permission, namely pcol.implies(new PropertyPermission("legacyParsing", "read")) returns true. Note: you may need to add the following permission to your java.policy in order to get protectionDomain at this point. permission java.lang.RuntimePermission "getProtectionDomain"; -- 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

16 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2366) PseudoClockScheduler should set the timer to the firing trigger's time

by Mark Proctor (JIRA)

PseudoClockScheduler should set the timer to the firing trigger's time ---------------------------------------------------------------------- Key: JBRULES-2366 URL: https://jira.jboss.org/jira/browse/JBRULES-2366 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core Reporter: Mark Proctor Assignee: Mark Proctor Fix For: 5.1.0.M2 -- 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

16 years, 1 month

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-2364) calendar support in drools

by Mark Proctor (JIRA)

calendar support in drools -------------------------- Key: JBRULES-2364 URL: https://jira.jboss.org/jira/browse/JBRULES-2364 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor Fix For: 5.1.0.M2 -- 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

16 years, 1 month

1
1
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 January 2010