<!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=675163712-09112007><FONT face=Arial
color=#0000ff size=2>OK, I understand.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=675163712-09112007><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=675163712-09112007><FONT face=Arial
color=#0000ff size=2>How does this differ to a regular import and Fact
insertion? At compile time you know the imports and create ObjectTypeNodes, and
when a sub-class is inserted.... then what?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=675163712-09112007></SPAN><SPAN
class=675163712-09112007><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=675163712-09112007><FONT face=Arial
color=#0000ff size=2>PS - are you in London or working late?
;-)</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> 09 November 2007 11:49<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> Michael,<BR><BR> No, it is good to
"speak loud" about the problem so I can think more about it while doing it.
:)<BR> The problem is related to class inheritance. At compile
time we know that a.b.c.Foo is an event and we create an ClassObjectTypeConf
for it, that says it is an event. At runtime, though, the user can insert
instances (facts) of absolutely any class in the working memory... even
classes for which there are no rules for. So, at runtime, when a fact of a
class that was never seen before is inserted into working memory, we need to
create a ClassObjectTypeConf for it, where we do a series of analysis (for
instance, at this time we decide if a shadow proxy is needed for it or not),
and at this time, we need to determine if this fact of a new "unknown" class
(lets say x.y.z.Bar) is an event or not (i.e, is it a subclass of a.b.c.Foo?).
<BR> So, back to my original e-mail, I can do that hierarchy
analysis to transparently determine that, but it is a costly operation. The
other alternative is assume that the user is explicit naming all event
classes, but that will not work for automatically generated classes (like when
using some XML binding frameworks). The last alternative is what your
suggested of having a specific API for that, but wouldn't we need to create a
checking algorithm anyway to prevent users mistakes?
<BR><BR> So, that is the dillemma...
:)<BR><BR> []s<BR> Edson<BR><BR>
<DIV><SPAN class=gmail_quote>2007/11/9, Anstis, Michael (M.) <<A
href="mailto:manstis1@ford.com">manstis1@ford.com</A>>:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff size=2>Hi
Edson,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff size=2>Sorry if
I'm causing more pain and grief than you ever intended your original posting
to cause.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff size=2>Now I
understand (more) the use case for Events I can better appreciate your
original dilemma. If you need the information to optimise the RETE network
at compile-time why do you need to perform the check when a Fact is
inserted; couldn't you have a new ObjectTypeNode that is specific to Event
classes? If my lack of knowledge is more of a hindrance let me know and I'll
revert to being a passive observer.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2>Cheers,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2>Mike</FONT></SPAN></DIV><FONT face=Arial color=#0000ff
size=2></FONT><FONT face=Arial color=#0000ff size=2></FONT><BR>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV lang=en-us dir=ltr align=left>
<HR>
<FONT face=Tahoma size=2><SPAN class=q><B>From:</B> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev-bounces@lists.jboss.org"
target=_blank>rules-dev-bounces@lists.jboss.org</A> [mailto:<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev-bounces@lists.jboss.org"
target=_blank>rules-dev-bounces@lists.jboss.org</A>] <B>On Behalf Of
</B>Edson Tirelli<BR></SPAN><B>Sent:</B> 08 November 2007 15:50</FONT>
<DIV><SPAN class=e id=q_11623e379ad1f367_3><FONT face=Tahoma
size=2><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></SPAN></DIV><BR></DIV>
<DIV><SPAN class=e id=q_11623e379ad1f367_5>
<DIV></DIV><FONT face=Arial color=#0000ff size=2></FONT><FONT face=Arial
color=#0000ff size=2></FONT><BR> Michael,<BR><BR>
The engine *must* know, at rulebase compile time, what classes represent
events. When I say it is for optimization purposes, is because events are
"light-weight" facts with special characteristics, but that occur in huge
volumes, and so, the engine will never scale without knowing they are
events. The way we can make the engine aware that a given class is an
event may vary: <BR><BR>* we can use some "declaration statement" in the
DRL like the ones I described<BR>* we can make the classes implement a
markup-interface like Matthias was suggesting<BR>* we can use keywords,
like iLog uses, writing "event" in every pattern that represents an event
<BR><BR> Besides what I commented in a previous e-mail
regarding the markup interfaces, having the declaration statement in the
DRL has an additional benefit of making clear to third-parties reading the
rules that those are event classes (that carry special characteristics).
<BR><BR> The idea here is to discuss exactly the
benefits and disadvantages of each approach. :)<BR><BR>
[]s<BR> Edson<BR><BR>
<DIV><SPAN class=gmail_quote>2007/11/8, Anstis, Michael (M.) <<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:manstis1@ford.com" target=_blank>
manstis1@ford.com</A>>:</SPAN>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff size=2>I
can turn that question around...</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><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><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><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><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN><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 lang=en-us dir=ltr align=left>
<HR>
<FONT face=Tahoma size=2><B>From:</B> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev-bounces@lists.jboss.org"
target=_blank>rules-dev-bounces@lists.jboss.org</A> [mailto:<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev-bounces@lists.jboss.org" target=_blank>
rules-dev-bounces@lists.jboss.org</A>] <B>On Behalf Of </B>Edson
Tirelli<BR><B>Sent:</B> 08 November 2007 14:54<BR><B>To:</B> Rules Dev
List</FONT>
<DIV><SPAN><FONT face=Tahoma size=2><BR><B>Subject:</B> Re:
[rules-dev] Determining if a class is an event or
not<BR></FONT></SPAN></DIV><BR></DIV>
<DIV><SPAN>
<DIV></DIV><BR> Michael,<BR><BR> 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> Anyway, the
API would solve this part of the problem, but the whole scenario is:
<BR> 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> <BR> 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> []s<BR> Edson<BR><BR>
<DIV><SPAN class=gmail_quote>2007/11/8, Anstis, Michael (M.) <<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:manstis1@ford.com" target=_blank>manstis1@ford.com
</A>>:</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
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev-bounces@lists.jboss.org"
target=_blank>rules-dev-bounces@lists.jboss.org</A><BR>[mailto:<A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev-bounces@lists.jboss.org" target=_blank>
rules-dev-bounces@lists.jboss.org</A>] On Behalf Of
Matthias<BR>Sent: 08 November 2007 13:09<BR>To: <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev@lists.jboss.org"
target=_blank>rules-dev@lists.jboss.org</A><BR>Subject: Re:
[rules-dev] Determining if a class is an event or not <BR><BR>Edson
Tirelli <tirelli <at> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://post.com" target=_blank>post.com</A>>
writes:<BR><BR>><BR>><BR>> All,
I reached a point where I need to make a design decision
and<BR>would<BR>like your opinion about it. Imagine the
following scenario: A user has a <BR>domain model like
this:package a.b.c<BR>> ;public interface Event { ... }package
x.y.z;public class MyEvent<BR>implements<BR>a.b.c.Event
{...} Then, in his DRL file he writes:package
p.q.r;import<BR>event<BR>a.b.c.* ; rule
Xwhen<BR>> Event( ...
)then ...end So, it is clear that
a.b.c.Event should<BR>be<BR>handled as an event by the
engine. 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>>
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. My question is: how the engine <BR>knows that
MyEvent is an event, since it only has the
x.y.z.MyEvent<BR>> class as input? 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>> 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>> 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>> Any better
idea? []s Edson --
Edson Tirelli Software<BR>Engineer<BR>- JBoss Rules Core
Developer Office: +55 11 3529-6000 Mobile: +55
11<BR>9287-5646<BR>> JBoss, a division of Red
Hat <at> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.jboss.com"
target=_blank>www.jboss.com</A><BR>><BR>><BR>>
_______________________________________________<BR>> rules-dev
mailing list<BR>> rules-dev <at> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://lists.jboss.org" target=_blank>lists.jboss.org
</A><BR>> <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR>><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 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
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev@lists.jboss.org"
target=_blank>rules-dev@lists.jboss.org</A><BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A>
<BR><BR>_______________________________________________<BR>rules-dev
mailing list<BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev@lists.jboss.org"
target=_blank>rules-dev@lists.jboss.org</A><BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR><BR><BR></BLOCKQUOTE></DIV><BR><BR
clear=all><BR>-- <BR> Edson Tirelli<BR> Software
Engineer - JBoss Rules Core Developer<BR> Office: +55 11
3529-6000<BR> Mobile: +55 11 9287-5646
<BR> JBoss, a division of Red Hat @ <A
onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.jboss.com" target=_blank>www.jboss.com</A>
</SPAN></DIV></BLOCKQUOTE></DIV><BR>_______________________________________________<BR>rules-dev
mailing list<BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev@lists.jboss.org"
target=_blank>rules-dev@lists.jboss.org</A><BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR><BR><BR
clear=all></BLOCKQUOTE></DIV><BR><BR clear=all><BR>--
<BR> Edson Tirelli<BR> Software Engineer - JBoss
Rules Core Developer<BR> Office: +55 11 3529-6000
<BR> Mobile: +55 11 9287-5646<BR> JBoss, a division
of Red Hat @ <A onclick="return top.js.OpenExtLink(window,event,this)"
href="http://www.jboss.com" target=_blank>www.jboss.com</A>
</SPAN></DIV></BLOCKQUOTE></DIV><BR>_______________________________________________<BR>rules-dev
mailing list<BR><A onclick="return top.js.OpenExtLink(window,event,this)"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</A><BR><A
onclick="return top.js.OpenExtLink(window,event,this)"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target=_blank>https://lists.jboss.org/mailman/listinfo/rules-dev</A><BR><BR><BR
clear=all></BLOCKQUOTE></DIV><BR><BR clear=all><BR>-- <BR> Edson
Tirelli<BR> Software Engineer - JBoss Rules Core
Developer<BR> Office: +55 11 3529-6000 <BR> Mobile: +55
11 9287-5646<BR> JBoss, a division of Red Hat @ <A
href="http://www.jboss.com">www.jboss.com</A> </BLOCKQUOTE></BODY></HTML>