<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.3132" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=099381115-08112007><FONT face=Arial 
color=#0000ff size=2>I can turn that question around...</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=099381115-08112007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=099381115-08112007><FONT face=Arial 
color=#0000ff size=2>If the user has written objects MyFact and MyEvent is it 
fair to expect them to have to declare it in the DRL?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=099381115-08112007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=099381115-08112007><FONT face=Arial 
color=#0000ff size=2>I don't know what Events are to do in Drools so don't which 
is the more reasonable approach. Is it just for network optimisation as you say, 
or will Drools be calling into members?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=099381115-08112007><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=099381115-08112007><FONT face=Arial 
color=#0000ff size=2>This is much more interesting than (my) work 
;-)</FONT></SPAN></DIV><BR>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>From:</B> rules-dev-bounces@lists.jboss.org 
  [mailto:rules-dev-bounces@lists.jboss.org] <B>On Behalf Of </B>Edson 
  Tirelli<BR><B>Sent:</B> 08 November 2007 14:54<BR><B>To:</B> Rules Dev 
  List<BR><B>Subject:</B> Re: [rules-dev] Determining if a class is an event or 
  not<BR></FONT><BR></DIV>
  <DIV></DIV><BR>&nbsp;&nbsp; Michael,<BR><BR>&nbsp;&nbsp; Yes, the 
  session.insertEvent() API is something other engines (like iLog JRules) have. 
  I initially discarded that idea, but since you mentioned, we may need to 
  reconsider it.<BR>&nbsp;&nbsp; Anyway, the API would solve this part of the 
  problem, but the whole scenario is: <BR>&nbsp;&nbsp; The engine must know at 
  the compile time exactly what classes/interfaces used in rules are events, so 
  that it can optimize the network. That is achievable by using any of the 
  syntaxes bellow (I'm not sure which one to use yet): <BR><BR>import event 
  a.b.c.Foo; (or)<BR>import event a.b.c.*;<BR><BR>or explicit 
  saying:<BR><BR>declare event a.b.c.Foo;<BR>&nbsp;<BR>&nbsp;&nbsp;&nbsp; Once 
  the user declared that something is an event, do you think it is 
  fair/acceptable to force the user to use a different API to insert events into 
  the engine? <BR><BR>session.insert(); for regular 
  facts<BR>session.insertEvent(); for events<BR><BR>&nbsp;&nbsp; 
  []s<BR>&nbsp;&nbsp; Edson<BR><BR>
  <DIV><SPAN class=gmail_quote>2007/11/8, Anstis, Michael (M.) &lt;<A 
  href="mailto:manstis1@ford.com">manstis1@ford.com </A>&gt;:</SPAN>
  <BLOCKQUOTE class=gmail_quote 
  style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Here's 
    my 2 cents - as a non-contributor to Drools codebase ;-)<BR><BR>You could 
    add insertEventFactTypeThingie to the API? Then you need just <BR>check that 
    the class has been declared as an event in the DRL similar to<BR>what must 
    already happen for normal DRL imports. I personally don't have<BR>issue with 
    implementing a marker interface (this is what frameworks like <BR>Hibernate, 
    EJB3 and Spring etc have been imposing for years). What "wiring"<BR>does the 
    POJO need to become an Event for use in Drools? Are you trying 
    to<BR>internalise too much at the risk of making the event mechanism 
    inflexible? <BR><BR>Cheers,<BR><BR>Mike<BR><BR>-----Original 
    Message-----<BR>From: <A 
    href="mailto:rules-dev-bounces@lists.jboss.org">rules-dev-bounces@lists.jboss.org</A><BR>[mailto:<A 
    href="mailto:rules-dev-bounces@lists.jboss.org"> 
    rules-dev-bounces@lists.jboss.org</A>] On Behalf Of Matthias<BR>Sent: 08 
    November 2007 13:09<BR>To: <A 
    href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</A><BR>Subject: 
    Re: [rules-dev] Determining if a class is an event or not <BR><BR>Edson 
    Tirelli &lt;tirelli &lt;at&gt; <A href="http://post.com">post.com</A>&gt; 
    writes:<BR><BR>&gt;<BR>&gt;<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;All,&nbsp;&nbsp; 
    I reached a point where I need to make a design decision 
    and<BR>would<BR>like your opinion about it.&nbsp;&nbsp; Imagine the 
    following scenario:&nbsp;&nbsp; A user has a <BR>domain model like 
    this:package a.b.c<BR>&gt; ;public interface Event { ... }package 
    x.y.z;public class MyEvent<BR>implements<BR>a.b.c.Event {...}&nbsp;&nbsp; 
    Then, in his DRL file he writes:package p.q.r;import<BR>event<BR>a.b.c.* 
    ;&nbsp;&nbsp;&nbsp;&nbsp;rule Xwhen<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Event( 
    ... )then&nbsp;&nbsp;&nbsp;&nbsp;...end&nbsp;&nbsp; So, it is clear that 
    a.b.c.Event should<BR>be<BR>handled as an event by the engine.&nbsp;&nbsp; 
    At runtime, the user asserts an object<BR>of<BR>the class x.y.z.MyEvent into 
    the working memory. Seems clear to me (and <BR>probably<BR>to the user) that 
    MyEvent should be handled as an event, since by DRL<BR>semantics,<BR>&gt; 
    a.b.c.* are all events, and by OO class hierarchy concept, 
    since<BR>a.b.c.Event<BR>is an event, x.y.z.MyEvent is an event 
    too.&nbsp;&nbsp; My question is: how the engine <BR>knows that MyEvent is an 
    event, since it only has the x.y.z.MyEvent<BR>&gt;&nbsp;&nbsp;class as 
    input?&nbsp;&nbsp; The only answer I have is that when the first 
    MyEvent<BR>instance is asserted into the working memory, we must get the 
    class name and <BR>iterate over all event import declarations checking for a 
    match. In case no<BR>one<BR>is found, we need to repeat the process for each 
    interface and each class up<BR>in<BR>the MyEvent hierarchy. Once this 
    process is complete, we cache the results <BR>in<BR>the 
    ObjectTypeConf.<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;This may be a quite heavy 
    process to be executed each time a fact of a<BR>different class is asserted 
    in the working memory for the first time, but I<BR>can't think a different 
    user-friendly way to solve the question. <BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;The 
    alternatives would be intrusive, IMO, breaking the drools 
    premise<BR>to<BR>work with user-defined POJOs as facts: use anotations to 
    annotate classes<BR>that<BR>are events, or mandate users implement a 
    specific interface for events. <BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Any better 
    idea?&nbsp;&nbsp;&nbsp;&nbsp;[]s&nbsp;&nbsp;&nbsp;&nbsp;Edson&nbsp;&nbsp;&nbsp;&nbsp;--&nbsp;&nbsp; 
    Edson Tirelli&nbsp;&nbsp;Software<BR>Engineer<BR>- JBoss Rules Core 
    Developer&nbsp;&nbsp;Office: +55 11 3529-6000&nbsp;&nbsp;Mobile: +55 
    11<BR>9287-5646<BR>&gt;&nbsp;&nbsp; JBoss, a division of Red 
    Hat&nbsp;&nbsp;&lt;at&gt;&nbsp;&nbsp; <A 
    href="http://www.jboss.com">www.jboss.com</A><BR>&gt;<BR>&gt;<BR>&gt; 
    _______________________________________________<BR>&gt; rules-dev mailing 
    list<BR>&gt; rules-dev &lt;at&gt; <A 
    href="http://lists.jboss.org">lists.jboss.org </A><BR>&gt; <A 
    href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR>&gt;<BR><BR><BR>Edson,<BR><BR>I 
    got your striving not to mandate users implement a specific interface for 
    <BR>events. However, why not at least introducing an empty event interface 
    (i.e.<BR>a<BR>marker interface, similar to the Serializable interface in 
    Java) the<BR>user-defined event class(es) have to implement? This way, when 
    inserting a <BR>MyEvent instance, you can simply check whether it implements 
    the event<BR>interface<BR>(by means of 'instanceof'). Moreover, while 
    parsing the import statements of<BR>a<BR>rule file, it enables you to 
    double-check whether all the "event imports" <BR>really<BR>refer to classes 
    implementing the (empty) event interface.<BR>In this regard, for me another 
    question raises: Without making any<BR>restrictions<BR>on the structure for 
    a user defined event class, how do you make sure it has 
    <BR>all<BR>the&nbsp;&nbsp;required attributes of an event (which in my 
    opinion must be a<BR>timestamp,<BR>at least) and how do you access them 
    (necessary for temporal relationships)?<BR>Having said this, in my opinion 
    defining an empty event interface may not be <BR>sufficient; in addition, it 
    must force the user to implement a method<BR>returning<BR>the event's 
    occurrence date (i.e. the timestamp) at least... Or how 
    would<BR>you<BR>handle this 
    issue?<BR><BR>Matthias<BR><BR>_______________________________________________ 
    <BR>rules-dev mailing list<BR><A 
    href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</A><BR><A 
    href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</A> 
    <BR><BR>_______________________________________________<BR>rules-dev mailing 
    list<BR><A 
    href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</A><BR><A 
    href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR><BR><BR></BLOCKQUOTE></DIV><BR><BR 
  clear=all><BR>-- <BR>&nbsp;&nbsp;Edson Tirelli<BR>&nbsp;&nbsp;Software 
  Engineer - JBoss Rules Core Developer<BR>&nbsp;&nbsp;Office: +55 11 
  3529-6000<BR>&nbsp;&nbsp;Mobile: +55 11 9287-5646 <BR>&nbsp;&nbsp;JBoss, a 
  division of Red Hat @ <A href="http://www.jboss.com">www.jboss.com</A> 
</BLOCKQUOTE></BODY></HTML>