June 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-3058) initializations in declare not applied for non-default constructor

by Wolfgang Laun (JIRA)

initializations in declare not applied for non-default constructor ------------------------------------------------------------------ Key: JBRULES-3058 URL: https://issues.jboss.org/browse/JBRULES-3058 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.2.0.CR1 Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.0 declare Person name : String @key nick : String = "Joe" end It can be shown that after Person p = new Person(); assert "Joe".equals( p.getNick() ); However after Person p = new Person( "Smith" ); assert p.getNick() == null; -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
11
0 / 0

[JBoss JIRA] Created: (JBRULES-3089) position of "dialect 'mvel'" affects function and/or rule parsing (NPE)

by Wolfgang Laun (JIRA)

position of "dialect 'mvel'" affects function and/or rule parsing (NPE) ----------------------------------------------------------------------- Key: JBRULES-3089 URL: https://issues.jboss.org/browse/JBRULES-3089 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.2.0.CR1 Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.0 The DRL shown below does not compile. Exchanging dialect and function fixes the problem, as does removing the dialect stmt. entirely. dialect "mvel" function boolean ping( String x ){ System.out.println( "ping " + x ); return true; } rule exa4 when eval( ping("A") ) then System.out.println( "Hello world!" ); end Unable to Analyse Expression ping("A"): [Error: unable to resolve method using strict-mode: java.lang.Object.ping(java.lang.String)] [Near : {... ping("A") ....}] ^ [Line: 1, Column: 1] : [Rule name='exa4'] Unable to build expression for 'eval':null 'ping("A")' : [Rule name='exa4'] java.lang.NullPointerException -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
11
0 / 0

[JBoss JIRA] Created: (JBRULES-3085) Serializing a package for KnowledgeAgent monitoring requires use of "unstable" API

by Wolfgang Laun (JIRA)

Serializing a package for KnowledgeAgent monitoring requires use of "unstable" API ----------------------------------------------------------------------------------- Key: JBRULES-3085 URL: https://issues.jboss.org/browse/JBRULES-3085 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-core (expert) Affects Versions: 5.2.0.CR1 Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.2.0 Serializing a compiled package seems a rational thing to do - after all, there is: <resource source="..." type="PKG" /> and it is recognized by the monitor. However, you can't simply serialize an org.drools.definition.KnowledgePackage as it is usually done by writing it to an ObjectOutputStream: deserialization in the KnowledgeAgent throws a CCE exception. To make it work, you must use a DroolsObjectOutputStream, which is nothing but a rename of ObjectOutputStream. So I have use DroolsObjectOutputStream, but it is not part of the public API. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
11
0 / 0

[JBoss JIRA] Created: (JBRULES-3074) Null pointer at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:103)

by Richard Ambridge (JIRA)

Null pointer at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:103) ----------------------------------------------------------------------------------------- Key: JBRULES-3074 URL: https://issues.jboss.org/browse/JBRULES-3074 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL Environment: Ubuntu Reporter: Richard Ambridge Assignee: Mark Proctor Priority: Blocker Attachments: DroolsRuleTest.java, Item.java, rule1.drl Using drools with time based rules and saliance, the saliance is not used when firing the rules This only happens when multiple objects update at the same time. e.g. Rule 1 is salience 1000 dialect "mvel" when $i : Item(val==10) Item(val==11, this after [0s, 1m] $i) Rule 2 is salience 1000 dialect "mvel" when $i : Item(val==10) not( Item(val==11, this after [0s,1m] $i)) Rule3 is salience 100 when $i : Item(val==11) Then we insert 3 items with val==10 Rule2 is activated 3 times... Then we insert an item with val==11 Note, with a val==10 and val==11 in the memory, Rule 1 will activate, and Rule 3 will activate However, Rule1 should fire first.. as its saliance is high For the first item it does, but then the Rule 3 fires before 2nd item does. Audit log is attached, but summary is Object inserted (1), Item: val==10 Activation created: Rule 2 (1) Object inserted (2), Item: val==10 Activation created: Rule 2 (2) Object inserted (3), Item: val==10 Activation created: Rule 2 (3) Object inserted (4), Item: val==11 Activation created: Rule 1 (1) Activation created: Rule 1 (2) Activation created: Rule 1 (3) Activation created: Rule 3 (4) Activation cancelled: Rule 2 (1) Activation cancelled: Rule 2 (2) Activation cancelled: Rule 2 (3) .. here we have 4 activations, 3 for Rule1 (saliance 1000), 1 for Rule3(saliance 100) Activation executed Rule 1 (1) Activation executed Rule 3 (4) //WRONG Activation cancelled: Rule 1 (2) Activation cancelled: Rule 1 (3) Activation created: Rule 2 (2) Activation created: Rule 2 (3) Note, this works fine in Drools 5.0 In Drools 5.2.0 CR1 a null pointer is thrown (another issue will be logged for that) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
12
0 / 0

[JBoss JIRA] Created: (JBRULES-3113) MVEL accepts funny comparison and evaluates without apparent semantics

by Wolfgang Laun (JIRA)

MVEL accepts funny comparison and evaluates without apparent semantics ---------------------------------------------------------------------- Key: JBRULES-3113 URL: https://issues.jboss.org/browse/JBRULES-3113 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler (expert) Affects Versions: 5.2.0.Final Reporter: Wolfgang Laun Assignee: Mark Proctor Fix For: 5.3.0.Beta1 Without "dialect 'mvel'", the funny expression in eval() is (correctly) refused by the compiler (" The operator == is undefined for the argument type(s) boolean, int"). Using MVEL, the rule compiles and fires, apparently with random values for $int3 and $long4: test5 1 1 65536 4294967296 test5 1 1 65568 4294967296 test5 1 1 65552 4294967296 test5 1 1 65536 65536 test5 1 1 65568 65536 test5 1 1 65552 65536 test5 1 1 65536 65568 test5 1 1 65536 65552 test5 1 1 65568 65568 test5 1 1 65552 65568 test5 1 1 65568 65552 test5 1 1 65552 65552 === DRL === dialect "mvel" rule kickOff when then insert( Integer.valueOf( 1 ) ); insert( Long.valueOf( 1 ) ); insert( Integer.valueOf( 65552 ) ); // 0x10010 insert( Long.valueOf( 65552 ) ); insert( Integer.valueOf( 65568 ) ); // 0x10020 insert( Long.valueOf( 65568 ) ); insert( Integer.valueOf( 65536 ) ); // 0x10000 insert( Long.valueOf( 65536L ) ); insert( Long.valueOf( 4294967296L ) ); // 0x100000000L end rule test5 salience 100 when $n1: Integer( $int1: intValue == 1 ) $n2: Long ( $long2: longValue ) $n3: Integer( this != $n1, $int3: intValue ) $n4: Long ( this != $n2, $long4: longValue ) eval( $int1 == $long2 == $int3 == $long4 ) then System.out.println( "test5 " + $int1 + " " + $long2 + " " + $int3 + " " + $long4 ); end -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

6
10
0 / 0

[JBoss JIRA] Created: (JBRULES-3096) Variable binding in DRL files not working as expected inside from accumulate CE

by Mauricio Salatino (JIRA)

Variable binding in DRL files not working as expected inside from accumulate CE ------------------------------------------------------------------------------- Key: JBRULES-3096 URL: https://issues.jboss.org/browse/JBRULES-3096 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 5.2.0.CR1, 5.3.0.M1 Reporter: Mauricio Salatino Assignee: Mark Proctor Fix For: 5.2.0 Attachments: variableBindingInsideAcc.zip This could be a grammar problem, it was working in 5.1.1 but now in 5.2.0.CR1 and in 5.3.0.SNAP is not working anymore. I'm attaching a file with the following two rules (the second commented) rule "test" when patient : Patient() $count: Number() from accumulate (dog: Dog(patientId == patient.id), count(dog)) // this gives a weird problem about not finding the class called patient (lowercase) then System.out.println("Dogs: "+ $count); end /*rule "test2" when $patient : Patient() $count: Number() from accumulate (dog: Dog(patientId == $patient.id), count(dog)) // this tries to resolve the $patient.id as the dog.id, not sure why then System.out.println("Dogs: "+ $count); end*/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
11
0 / 0

[JBoss JIRA] Created: (JBRULES-2616) Process persistent timers

by Diego Lopez Leon (JIRA)

Process persistent timers ------------------------- Key: JBRULES-2616 URL: https://jira.jboss.org/browse/JBRULES-2616 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-process Affects Versions: 5.1.0.FINAL Reporter: Diego Lopez Leon Assignee: Mark Proctor Implement a mechanism to allow scheduled timers to be triggered beyond the scope of a disposed session. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (AS7-1133) MSC service in war file is loaded from WEB-INF/classes/META-INF/services instead of META-INF/services

by David Bosschaert (JIRA)

MSC service in war file is loaded from WEB-INF/classes/META-INF/services instead of META-INF/services ----------------------------------------------------------------------------------------------------- Key: AS7-1133 URL: https://issues.jboss.org/browse/AS7-1133 Project: Application Server 7 Issue Type: Bug Components: MSC, Web Affects Versions: 7.0.0.CR1 Reporter: David Bosschaert Priority: Minor When deploying a .war file that contains a META-INF/service/org.jboss.msc.service.ServiceActivator this file is only processed when it's in the WEB-INF/classes/META-INF/services location, where I think it should really be picked up fro /META-INF/services -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-8824) Cardinality constraints on children are not enforced after parsing

by Brian Stansberry (JIRA)

Cardinality constraints on children are not enforced after parsing ------------------------------------------------------------------ Key: JBAS-8824 URL: https://issues.jboss.org/browse/JBAS-8824 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Priority: Critical Fix For: 7.0.0.Beta1 The parsers enforce cardinality constraints on child elements in the model, but they aren't enforced thereafter. So, for example, a second "profile" or "socket-binding-group" could be added to a standalone server via a management operation. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
5
0 / 0

[JBoss JIRA] Created: (JGRP-1317) STABLE: compress STABLE messages

by Bela Ban (JIRA)

STABLE: compress STABLE messages -------------------------------- Key: JGRP-1317 URL: https://issues.jboss.org/browse/JGRP-1317 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12.2, 3.1 For large clusters, stable messages are quite large, and should be compressed. E.g.: - Don't send the entire view (with all members), but only the ViewId, then the indices of a digest array would point to the rank of a member within the referred-to ViewId - A digest has 3 longs (low, highest_received and highest_delivered). Do we need all 3 every time ? - Compress the 3 longs into 1 long and 2 shorts: the latter 2 are offsets from the first seqno - Use a bit set (consisting of a variable number of ints) to set the 3 variables - If we have a digest (0), 0, 0: send a special marker - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect ! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
7
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 June 2011