May 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1987) Rule Flow support

by Taro Yasuma (JIRA)

Rule Flow support ----------------- Key: JBRULES-1987 URL: https://jira.jboss.org/jira/browse/JBRULES-1987 Project: JBoss Drools Issue Type: Task Security Level: Public (Everyone can see) Components: drools-docs, drools-docs-flow Affects Versions: 4.0.7 Reporter: Taro Yasuma Assignee: Mark Proctor Document Ruleflow in Drools 4.x was never supported. -- 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, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-2937) JtaTransactionManager should use setRollbackOnly instead of rollback for non-local transactions

by Vlastimil Menčík (JIRA)

JtaTransactionManager should use setRollbackOnly instead of rollback for non-local transactions ----------------------------------------------------------------------------------------------- Key: JBRULES-2937 URL: https://issues.jboss.org/browse/JBRULES-2937 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.2.0.M1 Environment: WinXP, Oracle Java 1.6.0_20, 32bit, JBoss AS 6.0.0.Final, jBPM 5.0.0 Reporter: Vlastimil Menčík Assignee: Mark Proctor This problem concerns the {{drools-persistence-jpa}} module and its {{org.drools.persistence.jta.JtaTransactionManager}}. The {{JtaTransactionManager}} has a notion of local transactions. These are the JTA transactions that it itself started using [UserTransaction.begin()|http://download.oracle.com/javaee/6/api/javax/tra...]. If a JTA transaction is already active when {{JtaTransactionManager.begin()}} is called, then the execution continues in this JTA transaction and a new one is not started. Let's call such JTA transaction non-local. The problem is that {{JtaTransactionManager.rollback()}} treats local and non-local JTA transactions the same way and calls [UserTransaction.rollback()|http://download.oracle.com/javaee/6/api/javax/...] in both cases. In case of a non-local transaction is this behaviour IMHO wrong, because the rollback should be a responsibility of the same client that started the JTA transaction. Imagine the following situation (jBPM process execution): {code} StatefulKnowledgeSession session = ... UserTransaction ut = ... ut.begin(); try { session.startProcess("my.process"); // the process execution may cause an exception (most likely in some WorkItemHandler) ut.commit(); } catch (Exception e) { ut.rollback(); // now this throws an IllegalStateException, because JtaTransactionManager already rolled back the transaction } {code} There is of course a workaround: the client code has to check [status|http://download.oracle.com/javaee/6/api/javax/transaction/UserTran...] of the JTA transaction and must not call {{rollback()}}, if the transaction was already rolled back by the {{JtaTransactionManager}}. IMHO the relevant JtaTransactionManager code should call [UserTransaction.setRollbackOnly|http://download.oracle.com/javaee/6/api/j...] for non-local transactions: {code} public void rollback() { boolean wasLocal = localTransaction; // localTransaction is a private boolean field of JtaTransactionManager already present in current implementation localTransaction = false; try { wasLocal ? this.ut.rollback() : this.ut.setRollbackOnly(); } catch ( Exception e ) { logger.warn( "Unable to rollback transaction", e); throw new RuntimeException( "Unable to rollback transaction", e ); } } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (JBRULES-1950) OSWorkflow

by Kris Verlaenen (JIRA)

OSWorkflow ---------- Key: JBRULES-1950 URL: https://jira.jboss.org/jira/browse/JBRULES-1950 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kris Verlaenen Assignee: Mark Proctor Provide a migration path for exising OSWorkflow users by being able to execute existing OSWorkflow processes on Drools Flow. -- 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, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1777) org.drools.reteoo.SchedulerTest.testDoLoopScheduledActivation failing on HP JVM (ia64)

by Lukas Petrovicky (JIRA)

org.drools.reteoo.SchedulerTest.testDoLoopScheduledActivation failing on HP JVM (ia64) -------------------------------------------------------------------------------------- Key: JBRULES-1777 URL: https://jira.jboss.org/jira/browse/JBRULES-1777 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.7 Reporter: Lukas Petrovicky Assignee: Mark Proctor org.drools.reteoo.SchedulerTest.testDoLoopScheduledActivation test is consistently failing on HP JVM. Only ia64, RISC is fine. Can be seen here: http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa43-rules-os-hp1... The reason it gives is: junit.framework.AssertionFailedError: expected:<4> but was:<3> at org.drools.reteoo.SchedulerTest.testDoLoopScheduledActivation(SchedulerTest.java:187) I'm testing with the version in SOA-P 4.3.0.GA_IR4. The version found in SOA-P 4.2.0 seems not to have such problem. -- 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, 7 months

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

[JBoss JIRA] Created: (AS7-828) Update poms to use plugin versions from jboss-parent

by Paul Gier (JIRA)

Update poms to use plugin versions from jboss-parent ---------------------------------------------------- Key: AS7-828 URL: https://issues.jboss.org/browse/AS7-828 Project: Application Server 7 Issue Type: Task Reporter: Paul Gier Assignee: Paul Gier Fix For: 7.0.0.CR1 Some of the modules define specific versions for plugins. In general, the build should just use the plugin versions inherited from the jboss-parent unless there is a requirement on a specific version. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1671) org.drools.integrationtests.DynamicRulesTest.testDynamicFunction fails with jrockit

by Jaroslaw Kijanowski (JIRA)

org.drools.integrationtests.DynamicRulesTest.testDynamicFunction fails with jrockit ----------------------------------------------------------------------------------- Key: JBRULES-1671 URL: http://jira.jboss.com/jira/browse/JBRULES-1671 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.7 Environment: http://anonsvn.labs.jboss.com/labs/jbossrules/tags/DROOLS_SOA_4_2_19937_CP2 Reporter: Jaroslaw Kijanowski Assigned To: Mark Proctor Please see SOA-621 for details, it affects the SOA branch -- 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-1670) org.drools.agent.RuleAgentTest.testDirectory fails on windows on jrockit

by Jaroslaw Kijanowski (JIRA)

org.drools.agent.RuleAgentTest.testDirectory fails on windows on jrockit ------------------------------------------------------------------------ Key: JBRULES-1670 URL: http://jira.jboss.com/jira/browse/JBRULES-1670 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.7 Environment: http://anonsvn.labs.jboss.com/labs/jbossrules/tags/DROOLS_SOA_4_2_19937_CP2 Reporter: Jaroslaw Kijanowski Assigned To: Mark Proctor Please see SOA-620 for details, it affects the SOA branch -- 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-2113) NPE thrown by LeftTuple.get() method

by Tom Murphy (JIRA)

NPE thrown by LeftTuple.get() method ------------------------------------ Key: JBRULES-2113 URL: https://jira.jboss.org/jira/browse/JBRULES-2113 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.0.0.CR1 Environment: FOund in 5.0.0.CR1 - Community version. Windows XP Reporter: Tom Murphy Assignee: Mark Proctor the get() method on LeftTuple throws a null exception under certain circumstances, which are as yet undetermined. Here is the Code: public InternalFactHandle get(final int index) { LeftTuple entry = this; while ( entry.index != index ) { entry = entry.parent; } return entry.handle; } Note that the loop moves to each parent in succession, but never checks for entry != null. If it does get to the end of the chain, it will throw an NPE -- 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, 7 months

3
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2011