March 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-711) BARRIER jmx beans not exposed

by Gray Watson (JIRA)

BARRIER jmx beans not exposed ----------------------------- Key: JGRP-711 URL: http://jira.jboss.com/jira/browse/JGRP-711 Project: JGroups Issue Type: Feature Request Affects Versions: 2.6.1 Reporter: Gray Watson Assigned To: Bela Ban Priority: Minor Attachments: BARRIER.java.patches The BARRIER protocol did not have any jmx information exposed. -- 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

18 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-706) with dynamic keys in ENCRYPT, a node taking over coordinator can block itself from taking over the view

by Gray Watson (JIRA)

with dynamic keys in ENCRYPT, a node taking over coordinator can block itself from taking over the view ------------------------------------------------------------------------------------------------------- Key: JGRP-706 URL: http://jira.jboss.com/jira/browse/JGRP-706 Project: JGroups Issue Type: Bug Affects Versions: 2.6.1 Environment: Linux test1a 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux CentOS. Reporter: Gray Watson Assigned To: Bela Ban This is with JGroups 2.6.1 on Linux 2.6.18, and a cluster of 10-20 nodes with several channels on each node. Everything is running smoothly, and then we kill the coordinator (of one or more channels), plus the next few nodes in the view, all at about the same time. SUSPECTs happen, and then the highest-ranking remaining node decides to become coordinator. It tries to mcast a new view, but never gets any view ACKs - so nobody else sees the updated view and the channel remains basically unusable. This only happens sometimes, and usually on just some of several channels - even though they share the same stack config. Enabling TRACE logging revealed that ENCRYPT.down() is queuing the new view - we use dynamically-generated keys and apparently the view changes have flipped queue_down to 'true'. We see this, over and over: 2008-03-02 10:54:47,970 [TRACE] GMS mcasting view {[10.193.48.119:33274|693] [10.193.48.119:33274, 10.193.48.115:52962, 10.192.226.30:45130, 10.193.66.111:43645]} (4 mbrs) 2008-03-02 10:54:47,970 [TRACE] ENCRYPT queueing down message as no session key established[dst: <null>, src: <null> (1 headers), size=0 bytes] 2008-03-02 10:54:49,972 [WARN] GMS failed to collect all ACKs (4) for view [10.193.48.119:33274|693] [10.193.48.119:33274, 10.193.48.115:52962, 10.192.226.30:45130, 10.193.66.111:43645] after 2000ms, missing ACKs from [10.193.48.119:33274, 10.193.48.115:52962, 10.192.226.30:45130, 10.193.66.111:43645] (received=[]), local_addr=10.193.48.119:33274 -- 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

18 years, 2 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1452) Improved NullPointerException messages

by mike mcmahon (JIRA)

Improved NullPointerException messages -------------------------------------- Key: JBRULES-1452 URL: http://jira.jboss.com/jira/browse/JBRULES-1452 Project: JBoss Drools Issue Type: Patch Security Level: Public (Everyone can see) Affects Versions: 4.0.4, 4.0.3, 4.0.2, 4.0.1, 4.0.0.GA, 4.0.0.MR3, 4.0.0.MR2 Reporter: mike mcmahon Fix For: 4.0.5 Currently, there are many places in drools-core which can (potentially) throw NullPointerException. The error message contains no information about which Rule or which item/property in working memory caused the NPE, and this makes it very difficult to fix the Rule or working memory data. The patch below (relative to 4.0.4) adds some valuable information to aid in fixing Rules. Index: org/drools/base/evaluators/DateFactory.java =================================================================== --- org/drools/base/evaluators/DateFactory.java (revision 18270) +++ org/drools/base/evaluators/DateFactory.java (working copy) @@ -282,6 +282,8 @@ } final Date value1 = (Date) extractor1.getValue( workingMemory, object1 ); final Date value2 = (Date) extractor2.getValue( workingMemory, object2 ); + if (null == value2) + throw new NullPointerException(extractor2.toString()); return value1.compareTo( value2 ) < 0; } @@ -342,6 +344,8 @@ } final Date value1 = (Date) extractor1.getValue( workingMemory, object1 ); final Date value2 = (Date) extractor2.getValue( workingMemory, object2 ); + if (null == value2) + throw new NullPointerException(extractor2.toString()); return value1.compareTo( value2 ) <= 0; } @@ -402,6 +406,8 @@ } final Date value1 = (Date) extractor1.getValue( workingMemory, object1 ); final Date value2 = (Date) extractor2.getValue( workingMemory, object2 ); + if (null == value2) + throw new NullPointerException(extractor2.toString()); return value1.compareTo( value2 ) > 0; } @@ -462,6 +468,8 @@ } final Date value1 = (Date) extractor1.getValue( workingMemory, object1 ); final Date value2 = (Date) extractor2.getValue( workingMemory, object2 ); + if (null == value2) + throw new NullPointerException(extractor2.toString()); return value1.compareTo( value2 ) >= 0; } Index: org/drools/rule/EvalCondition.java =================================================================== --- org/drools/rule/EvalCondition.java (revision 18270) +++ org/drools/rule/EvalCondition.java (working copy) @@ -73,7 +73,7 @@ this.requiredDeclarations, workingMemory ); } catch ( final Exception e ) { - throw new RuntimeDroolsException( e ); + throw new RuntimeDroolsException( this.getEvalExpression() + " : " + e ); } } -- 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

18 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1386) OC4J Support

by Jason Lee (JIRA)

OC4J Support ------------ Key: JBRULES-1386 URL: http://jira.jboss.com/jira/browse/JBRULES-1386 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.1.0 Environment: OC4J 10.1.3.3 Reporter: Jason Lee Priority: Minor The current nightly build fails to deploy and/or run on OC4J 10.1.3.3. To fix this, I did the following: * Upgrade jboss-seam to 2.0.0 CVS (GA might work, but I added some logging to org.jboss.seam.init.Initialization to help track down deployment issues) * Upgrade jboss-el to 2.0.0.GA * Added Mojarra 1.2_07 jars * Added the following to web.xml: <context-param> <param-name> com.sun.faces.forceLoadConfiguration</param-name> <param-value>true</param-value> </context-param> -- 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

18 years, 2 months

3
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1487) access to store property in MapBackedClassLoader should be synchronized

by Jan Boboli (JIRA)

access to store property in MapBackedClassLoader should be synchronized ----------------------------------------------------------------------- Key: JBRULES-1487 URL: http://jira.jboss.com/jira/browse/JBRULES-1487 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.4 Reporter: Jan Boboli Assigned To: Mark Proctor In MapBackedClassLoader three methods have access to the "store" property - addClass, fastFindClass and getResourceAsStream. fastFindClass is used in synchronized loadClass method, but addClass modifies the store without any synchronization. MapBackedClassLoader is connected to one rulebase which can be shared between different working memory, so it is possible that multiple threads access the store concurently. -- 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

18 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1338) DirectoryScanner should only take into account relevant files

by Jￃﾶrg Erdmenger (JIRA)

DirectoryScanner should only take into account relevant files ------------------------------------------------------------- Key: JBRULES-1338 URL: http://jira.jboss.com/jira/browse/JBRULES-1338 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Jￃﾶrg Erdmenger Currently DirectoryScanner in its configure and loadPackageChanges methods takes into account all types of files and hands them to FileScanner. This causes issues when the directory specified is under source management control (at least if CVS or Subversion are used) as the .svn or similar files/dirs cause FileScanner to barf. Now I'm sure that for plenty of cases the dir passed to DirectoryScanner won't be SCM managed but I think there might also be lots of situations where it is. Considering that it would be such a trivial change to either: - only take into account .pkg and .drl files (or do we need .dsl, .rf as well) - or at least ignore dot files (and maybe directories in general?) I think it will be worth doing. -- 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

18 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1440) Support for Nested Templates

by greywind (JIRA)

Support for Nested Templates ---------------------------- Key: JBRULES-1440 URL: http://jira.jboss.com/jira/browse/JBRULES-1440 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Affects Versions: 4.0.4 Reporter: greywind I have to need to use fact templates but I still want to be able to use nested properties. Currently I cannot do that fully. What I can do is what is in attachment 'current'. What I would like to do is in attachment 'wanted' -- 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

18 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-1225) allow dump of generated .java files during rule compilation

by Godmar Back (JIRA)

allow dump of generated .java files during rule compilation ----------------------------------------------------------- Key: JBRULES-1225 URL: http://jira.jboss.com/jira/browse/JBRULES-1225 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.1 Reporter: Godmar Back Assigned To: Mark Proctor Please add an option to dump the generated .java code. Otherwise, debugging compile errors is a night mare. Even when dialect "MVEL" isn't used, some expression seem to become MVEL expressions. In addition, it seems that bean-Syntax (as in x.prop) can be used in the conditions of a rule, but the consequence requires that you use x.getProp()). It's also not clear in which scope/package/class the generated code lives. -- 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

18 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1446) ClassCastException when iterating over an array using "from"

by Krzysztof Karski (JIRA)

ClassCastException when iterating over an array using "from" ------------------------------------------------------------ Key: JBRULES-1446 URL: http://jira.jboss.com/jira/browse/JBRULES-1446 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.4 Environment: Windows XP Reporter: Krzysztof Karski To reproduce the error, please create the two following objects: package test; public class DomainObject { private String message; private int value; private double value2; public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } public int getValue() { return value; } public void setValue(int value) { this.value = value; } public double getValue2() { return value2; } public void setValue2(double value2) { this.value2 = value2; } } package test; public class DomainObjectHolder { DomainObject[] objects = new DomainObject[3]; public DomainObjectHolder(){ objects[0] = new DomainObject(); objects[0].setMessage("Message1"); objects[0].setValue(1); objects[0].setValue2(2); objects[1] = new DomainObject(); objects[1].setMessage("Message2"); objects[1].setValue(3); objects[1].setValue2(4); objects[2] = new DomainObject(); objects[2].setMessage("Message3"); objects[2].setValue(5); objects[2].setValue2(6); } public DomainObject[] getObjects(){ return objects; } } Here are a few rule that will trigger the ClassCastException: rule "Test Rule" when $holder : DomainObjectHolder() $object : DomainObject( $message : message) from $holder.objects; then System.out.println("Selected Object " + $message); end rule "Test Rule" when $holder : DomainObjectHolder() $object : DomainObject( ) from $holder.objects; then System.out.println("Selected Object " + $object.getMessage()); end This rule does not trigger the exception: rule "Test Rule" when $holder : DomainObjectHolder() $object : DomainObject( ) from $holder.objects; then System.out.println("Selected Object"); end Here is the exception message: java.lang.ClassCastException: [Ltest.DomainObject; cannot be cast to test.DomainObject at org.drools.base.test.DomainObject9939622$getMessage.getValue(Unknown Source) at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:127) at org.drools.rule.Declaration.getValue(Declaration.java:198) at sequitem.quanteq.rules.exit.Rule_Test_Rule_0ConsequenceInvoker.evaluate(Rule_Test_Rule_0ConsequenceInvoker.java:17) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) at sequitem.quanteq.rules.engine.StatefulEngine.execute(StatefulEngine.java:98) at sequitem.quanteq.rules.engine.StatefulEngine.execute(StatefulEngine.java:45) at sequitem.quanteq.tradesystem.RuleBasedTradeSystem.onStart(RuleBasedTradeSystem.java:186) at org.activequant.tradesystem.simple.TradeSystemBase.start(TradeSystemBase.java:242) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.activequant.container.context.TradeSystemContextBase.invoke(TradeSystemContextBase.java:134) at org.activequant.container.context.TradeSystemContextBase.access$2(TradeSystemContextBase.java:132) at org.activequant.container.context.TradeSystemContextBase$2.start(TradeSystemContextBase.java:152) at org.activequant.container.context.TradeSystemContextBase.start(TradeSystemContextBase.java:179) at sequitem.quanteq.backtest.exits.StandardExistBackTest.main(StandardExistBackTest.java:36) Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.activequant.container.context.TradeSystemContextBase.invoke(TradeSystemContextBase.java:134) at org.activequant.container.context.TradeSystemContextBase.access$2(TradeSystemContextBase.java:132) at org.activequant.container.context.TradeSystemContextBase$2.start(TradeSystemContextBase.java:152) at org.activequant.container.context.TradeSystemContextBase.start(TradeSystemContextBase.java:179) at sequitem.quanteq.backtest.exits.StandardExistBackTest.main(StandardExistBackTest.java:36) Caused by: org.drools.spi.ConsequenceException: java.lang.ClassCastException: [Ltest.DomainObject; cannot be cast to test.DomainObject at org.drools.base.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:14) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:554) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) at sequitem.quanteq.rules.engine.StatefulEngine.execute(StatefulEngine.java:98) at sequitem.quanteq.rules.engine.StatefulEngine.execute(StatefulEngine.java:45) at sequitem.quanteq.tradesystem.RuleBasedTradeSystem.onStart(RuleBasedTradeSystem.java:186) at org.activequant.tradesystem.simple.TradeSystemBase.start(TradeSystemBase.java:242) ... 9 more Caused by: java.lang.ClassCastException: [Ltest.DomainObject; cannot be cast to test.DomainObject at org.drools.base.test.DomainObject9939622$getMessage.getValue(Unknown Source) at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:127) at org.drools.rule.Declaration.getValue(Declaration.java:198) at sequitem.quanteq.rules.exit.Rule_Test_Rule_0ConsequenceInvoker.evaluate(Rule_Test_Rule_0ConsequenceInvoker.java:17) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) ... 16 more -- 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

18 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1501) Multiples modify causes variable duplication exception

by Fernando Meyer (JIRA)

Multiples modify causes variable duplication exception ------------------------------------------------------- Key: JBRULES-1501 URL: http://jira.jboss.com/jira/browse/JBRULES-1501 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.4 Reporter: Fernando Meyer Assigned To: Fernando Meyer Priority: Critical Fix For: 4.0.5, 5.0.0-M1 -- 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

18 years, 2 months

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