[rules-users] Hi
rules-users@lists.jboss.org this is something you cant miss http://www.news13inow.com/ talk to you later ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] NPE on fact insertion if rule has sliding window
laune wrote: There's a bug in the incremental build as done by the KnowledgeAgent. If the KA configuration property drools.agent.newInstance is set to false, some type information is not put into the new KBase. I added the following comment to the JIRA related to this issue (https://issues.jboss.org/browse/JBRULES-3145). Cross-posting here in case anyone else is having the issue and arrives here via Google like I did. I am seeing the same behavior with my KA newInstance = true. I was able to workaround it by ensuring that my event POJOs are defined in the same package as my rules. In other words, this DOES NOT work: Rule package: com.example.rules POJO package: com.example.rules.model (import statements included in DRL) This DOES work: Rule package: com.example.rules POJO package: com.example.rules (no import statements required) I did not have to move my event declaration to my DRL; they are still POJOs. I would prefer to have my POJOs in their own package but I can live with this workaround for now. Mike -- View this message in context: http://drools.46999.n3.nabble.com/NPE-on-fact-insertion-if-rule-has-sliding-window-tp3163261p3403934.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Sessions both Stateful n Stateless giving issues
you are invoking fireAllRules() separately before your commands are executed, so your rules fire before any objects are inserted. instead of demographicStatefulKSession.fireAllRules(); add command: demoCmds.add(CommandFactory.newFireAllRules()); -- View this message in context: http://drools.46999.n3.nabble.com/Sessions-both-Stateful-n-Stateless-giving-issues-tp3402876p3403937.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] NPE on fact insertion if rule has sliding window
This is fixed in master. Will be in 3.1 final release. Edson 2011/10/7 mike9322 michael.melton@navy.mil laune wrote: There's a bug in the incremental build as done by the KnowledgeAgent. If the KA configuration property drools.agent.newInstance is set to false, some type information is not put into the new KBase. I added the following comment to the JIRA related to this issue (https://issues.jboss.org/browse/JBRULES-3145). Cross-posting here in case anyone else is having the issue and arrives here via Google like I did. I am seeing the same behavior with my KA newInstance = true. I was able to workaround it by ensuring that my event POJOs are defined in the same package as my rules. In other words, this DOES NOT work: Rule package: com.example.rules POJO package: com.example.rules.model (import statements included in DRL) This DOES work: Rule package: com.example.rules POJO package: com.example.rules (no import statements required) I did not have to move my event declaration to my DRL; they are still POJOs. I would prefer to have my POJOs in their own package but I can live with this workaround for now. Mike -- View this message in context: http://drools.46999.n3.nabble.com/NPE-on-fact-insertion-if-rule-has-sliding-window-tp3163261p3403934.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] NPE on fact insertion if rule has sliding window
Edson, you mean 5.3.Final? sent on the move On 7 Oct 2011 21:08, Edson Tirelli ed.tire...@gmail.com wrote: This is fixed in master. Will be in 3.1 final release. Edson 2011/10/7 mike9322 michael.melton@navy.mil laune wrote: There's a bug in the incremental build as done by the KnowledgeAgent. If the KA configuration property drools.agent.newInstance is set to false, some type information is not put into the new KBase. I added the following comment to the JIRA related to this issue (https://issues.jboss.org/browse/JBRULES-3145). Cross-posting here in case anyone else is having the issue and arrives here via Google like I did. I am seeing the same behavior with my KA newInstance = true. I was able to workaround it by ensuring that my event POJOs are defined in the same package as my rules. In other words, this DOES NOT work: Rule package: com.example.rules POJO package: com.example.rules.model (import statements included in DRL) This DOES work: Rule package: com.example.rules POJO package: com.example.rules (no import statements required) I did not have to move my event declaration to my DRL; they are still POJOs. I would prefer to have my POJOs in their own package but I can live with this workaround for now. Mike -- View this message in context: http://drools.46999.n3.nabble.com/NPE-on-fact-insertion-if-rule-has-sliding-window-tp3163261p3403934.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] NPE on fact insertion if rule has sliding window
Lol, I guess I need a cup of coffee. Yes, that was what I meant. Edson 2011/10/7 Michael Anstis michael.ans...@gmail.com Edson, you mean 5.3.Final? sent on the move On 7 Oct 2011 21:08, Edson Tirelli ed.tire...@gmail.com wrote: This is fixed in master. Will be in 3.1 final release. Edson 2011/10/7 mike9322 michael.melton@navy.mil laune wrote: There's a bug in the incremental build as done by the KnowledgeAgent. If the KA configuration property drools.agent.newInstance is set to false, some type information is not put into the new KBase. I added the following comment to the JIRA related to this issue (https://issues.jboss.org/browse/JBRULES-3145). Cross-posting here in case anyone else is having the issue and arrives here via Google like I did. I am seeing the same behavior with my KA newInstance = true. I was able to workaround it by ensuring that my event POJOs are defined in the same package as my rules. In other words, this DOES NOT work: Rule package: com.example.rules POJO package: com.example.rules.model (import statements included in DRL) This DOES work: Rule package: com.example.rules POJO package: com.example.rules (no import statements required) I did not have to move my event declaration to my DRL; they are still POJOs. I would prefer to have my POJOs in their own package but I can live with this workaround for now. Mike -- View this message in context: http://drools.46999.n3.nabble.com/NPE-on-fact-insertion-if-rule-has-sliding-window-tp3163261p3403934.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Map errors and quirks
I have a large pool of errors I would like help with but I am breaking them
up by topic since they are so different in nature. I have made fairly
simple examples to start.
Environment : Using drools 5.2.0.Final on Linux using the openjdk 6 JDK.
First are some bugs in Map access when using a local variable or a object
variable as key. This is a very simple case which gets more complicated in
my next example in this email. The rule file will not compile despite
appearing logically valid to me.
/* simple example class */
package com.sample;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;
public class Mailbox {
static public final String TEST_EMAIL = m...@test.com;
public Maplt;String, Dategt; recentContacts = new HashMaplt;String,
Dategt;();
public Mailbox() {
owneremail = TEST_EMAIL;
// create contact for self
recentContacts.put(owneremail, new Date());
}
public Maplt;String, Dategt; getRecentContacts() {
return recentContacts;
}
}
/* simple rule file */
// this rule is nonsensical but attempts hashmap access via many means to
find out why
// behavior was inconsistant. Each commented line will cause file to not
compile when uncommented.
// the uncommented lines are present to show what does work.
package com.sample
import java.util.Date;
import java.util.Map;
import com.sample.Mailbox;
rule check recentContacts hash mvel
dialect mvel
when
$m : Mailbox(
// Each commented line will result in the file no
longer compiling
if uncommented
$me : owneremail,
recentContacts[Mailbox.TEST_EMAIL] != null,
recentContacts[m...@test.com] != null,
// recentContacts[owneremail] != null, // HAS ERROR
because it checks
HashMap for owneremail
recentContacts[$me] != null,
$d1 : recentContacts[Mailbox.TEST_EMAIL],
$d2 : recentContacts[m...@test.com],
// $d3 : recentContacts[$me], // HAS ERROR only when doing
variable
assignment
recentContacts.get(owneremail) != null,
recentContacts.get($me) != null,
// $d4: recentContacts.get($me), // HAS ERROR only if
doing variable
assignment
$d5 : getRecentContacts(),
$d6 : getRecentContacts().size,
0 1
)
then
System.out.println( recentContacts were accessible );
end
Any suggestions? Not being able to access objects in a hash is problematic.
And it gets worse if objects are not base java classes as I find even static
enums getting handled erratically when used as keys. Some time I need to
use the full name but using a method I can use different expression and have
it work. Moving to next problem now this is my real problem. Please note
that I was not initially usign an inner static enum but moved it there to
make example a single file.
/* more complicated version of class */
package com.sample;
import java.util.ArrayList;
import java.util.Date;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class Mailbox {
// taken straight form example code
static public class Message {
public static final int HELLO = 0;
public static final int GOODBYE = 1;
private String message;
private int status;
public String getMessage() {
return this.message;
}
public void setMessage(String message) {
this.message = message;
}
public int getStatus() {
return this.status;
}
public void setStatus(int status) {
this.status = status;
}
}
static public enum FolderType {INBOX, SENT, TRASH};
static public final String TEST_EMAIL = m...@test.com;
private Maplt;FolderType, Listlt;Messagegt; folders = new
HashMaplt;FolderType, Listlt;Messagegt;();
public Maplt;String, Dategt; recentContacts = new HashMaplt;String,
Dategt;();
private String owneremail;
public Mailbox(String username) {
owneremail = username;
// create contact for self
recentContacts.put(owneremail, new Date());
// create default folders
folders.put(FolderType.SENT, new ArrayListMessage());
folders.put(FolderType.TRASH, new ArrayListMessage());
folders.put(FolderType.INBOX, new ArrayListMessage());
}
/** parameterized accessor */
public ListMessage getFolder(FolderType t) {
return folders.get(t);
}
Re: [rules-users] Map errors and quirks
Hi,
Thanks for the very comprehensive description. We did a lot of fixes
related to syntax problems and map support in the last few weeks. In
particular, I believe the problems reported in your first item are all
solved.
Can you please test with the latest snapshot? Don't forget to update your
MVEL jar as well.
https://hudson.jboss.org/jenkins/view/Drools%20jBPM/job/drools/lastSuccessfulBuild/artifact/drools-distribution/target/
For the second item, it may or may not be fixed. If you can check with
the latest snapshot and open a JIRA in case it is not working, I will fix it
and include in the 5.3.final release.
Thanks,
Edson
2011/10/7 zstlaw zstla...@akamai.com
I have a large pool of errors I would like help with but I am breaking them
up by topic since they are so different in nature. I have made fairly
simple examples to start.
Environment : Using drools 5.2.0.Final on Linux using the openjdk 6 JDK.
First are some bugs in Map access when using a local variable or a object
variable as key. This is a very simple case which gets more complicated in
my next example in this email. The rule file will not compile despite
appearing logically valid to me.
/* simple example class */
package com.sample;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;
public class Mailbox {
static public final String TEST_EMAIL = m...@test.com;
public Maplt;String, Dategt; recentContacts = new
HashMaplt;String,
Dategt;();
public Mailbox() {
owneremail = TEST_EMAIL;
// create contact for self
recentContacts.put(owneremail, new Date());
}
public Maplt;String, Dategt; getRecentContacts() {
return recentContacts;
}
}
/* simple rule file */
// this rule is nonsensical but attempts hashmap access via many means to
find out why
// behavior was inconsistant. Each commented line will cause file to not
compile when uncommented.
// the uncommented lines are present to show what does work.
package com.sample
import java.util.Date;
import java.util.Map;
import com.sample.Mailbox;
rule check recentContacts hash mvel
dialect mvel
when
$m : Mailbox(
// Each commented line will result in the file no
longer compiling
if uncommented
$me : owneremail,
recentContacts[Mailbox.TEST_EMAIL] != null,
recentContacts[m...@test.com] != null,
// recentContacts[owneremail] != null, // HAS ERROR
because it checks
HashMap for owneremail
recentContacts[$me] != null,
$d1 : recentContacts[Mailbox.TEST_EMAIL],
$d2 : recentContacts[m...@test.com],
// $d3 : recentContacts[$me], // HAS ERROR only when
doing variable
assignment
recentContacts.get(owneremail) != null,
recentContacts.get($me) != null,
// $d4: recentContacts.get($me), // HAS ERROR only if
doing variable
assignment
$d5 : getRecentContacts(),
$d6 : getRecentContacts().size,
0 1
)
then
System.out.println( recentContacts were accessible );
end
Any suggestions? Not being able to access objects in a hash is
problematic.
And it gets worse if objects are not base java classes as I find even
static
enums getting handled erratically when used as keys. Some time I need to
use the full name but using a method I can use different expression and
have
it work. Moving to next problem now this is my real problem. Please note
that I was not initially usign an inner static enum but moved it there to
make example a single file.
/* more complicated version of class */
package com.sample;
import java.util.ArrayList;
import java.util.Date;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class Mailbox {
// taken straight form example code
static public class Message {
public static final int HELLO = 0;
public static final int GOODBYE = 1;
private String message;
private int status;
public String getMessage() {
return this.message;
}
public void setMessage(String message) {
this.message = message;
}
public int getStatus() {
return this.status;
}
public void setStatus(int status) {
this.status = status;
}
}
static public enum FolderType {INBOX, SENT, TRASH};
static public final String TEST_EMAIL = m...@test.com;
private Maplt;FolderType, Listlt;Messagegt; folders = new
HashMaplt;FolderType, Listlt;Messagegt;();
public
Re: [rules-users] NPE in SlidingTimeWindow$SlidingTimeWindowComparator
Hi Rob, Can you please provide the test case (open a JIRA with it) or at least a description of what kind of events are you feeding in and with which frequency so that we can try to reproduce the problem? The NPE where you mentioned is the symptom... the problem is elsewhere... Edson 2011/10/6 Rob Crawford crawf...@kloognome.com I'm getting a null pointer exception on either line 232 or 233 of SlidingTimeWindow. The only window I'm using is: rule Mark up to date timer(int: 5m) when $store: Store() exists (SensorReading (this.store == $store) over window:time(5m)) then ... end The rule never fires; this happens when the sliding time window is expiring tuples. It appears the comparator needs to handle nulls, but there's nothing in the JavaDocs about that. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
