<br> Mike,<br><br> Good question. <br> Since I'm playing "devil's advocate" here, imagine the scenario:<br><br>* There is an event stream that the user wants to process with our engine. The stream has events of types (classes) A, B and C, all of them from package
x.y.z. So, the user writes in the DRL:<br><br>import events x.y.z.*;<br><br>Although, at this time, the user is only interested in events of type A, and so only writes rules for event type A. So, the engine will only create (at rulebase compile time) ObjectTypeNodes for class A. Since one of the jobs of an ESP engine is to select only the events the user is interested in, the engine must discard events B and C. But a rules engine, only automatically discards events, not facts, and as so, the engine must know that B and C are events and the user is not interested in them, but using existing ObjectTypes to determine if B and C are events, will not help in this case.
<br><br> So, with regular facts, Drools does exactly what you said, but with events, an additional verification must be made to determine at runtime if a given class is an event class or not. That is the difference we are looking a solution for.
<br><br> Edson<br><br><div><span class="gmail_quote">2007/11/13, Anstis, Michael (M.) <<a href="mailto:manstis1@ford.com">manstis1@ford.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">Option (3) fits in best with the current way Drools exposes
itself to users (we don't need to implement an interface for regular facts, or
shadow facts) but would like to understand how it differs to the insertion of
regular facts: a user imports a class but can insert a sub-class, so it appears
this would need to perform the same type of inheritance check as Edson is
proposing for (3) to ensure the correct ObjectTypeNode is selected... it
could well be that (3) is no different to how regular facts are propagated
through the network.</font></span></div><br>
<blockquote style="margin-right: 0px;">
<div dir="ltr" align="left" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev-bounces@lists.jboss.org</a>
[mailto:<a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev-bounces@lists.jboss.org</a>] <b>On Behalf Of </b>Edson
Tirelli<br><b>Sent:</b> 12 November 2007 19:25<div><span class="e" id="q_11638558222afb33_1"><br><b>To:</b> Rules Dev
List<br><b>Subject:</b> Re: [rules-dev] Determining if a class is an event or
not<br></span></div></font><br></div><div><span class="e" id="q_11638558222afb33_3">
<div></div><br> Felipe,<br><br> I see your
point and maybe you are right. I will do some more research till tomorrow and
then start implementing that. Let's see how much overhead solution 3 adds and
if it is worth to have options 1 and/or 2. <br> Just to make
it clear, we are talking about use cases where the rules USE events, i.e.,
CEP/ESP use cases. All these must have NO impact on rulebases that do not use
events, as it is today.<br><br> CEP/ESP support and Temporal
Reasoning are a set of features we are working on for the next major release.
It is in early design/implementation phases now and we have no docs yet.
<br> Anyone interested in that is more than welcome to join
discussions like the one in this thread, contribute ideas, code and docs. We
are an open source product after all... :)<br><br>
Regards,<br> Edson<br><br>
<div><span class="gmail_quote">2007/11/12, Felipe Piccolini <<a href="mailto:felipe.piccolini@bluesoft.cl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">felipe.piccolini@bluesoft.cl</a>>:
</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Edson,
<div><br></div>
<div>As I see it,</div>
<div><br></div>
<div> Solutions (1) and (2) lend the responsabilitie of knowing
what they are doing on developers, and can be tricky...but at the end could
be</div>
<div>an optimal solution...so they should exists.. solution (3) makes all
the work clean and easy, but can introduce over load work, so for
first</div>
<div>instance I'll set up solution (3) so an advanced developer coul
deactivated by developer with some config API, so they could make their
</div>
<div>application work faster if they know what they are doing... </div>
<div><br></div>
<div>OF course i dont like to break the POJO paradigm on drools, is one of
the things make drools THE choice... but introduce extra check to </div>
<div>add a feature that maybe not all devs will use is something that an
advanced dev should decide...</div>
<div><br></div>
<div>my 2 cents..</div>
<div><br></div>
<div>:) </div>
<div><br></div>
<div>btw: Im a little lost on this event feature (last moths Iv been working
on other things) so, where can I read about this event handle?..is a new
</div>
<div>feature from 4.0.2?...is on the docs? Thx.</div>
<div><span>
<div><br></div>
<div><br>
<div>
<div>On 12-11-2007, at 13:54, Edson Tirelli wrote:</div><br>
<blockquote type="cite"><br> Mike, Felipe and
Matthias,<br><br> Thank you for all your feedback. It really
helps to understand the different point of views.<br> I will
try to summarize my understanding of the issue based on your comments so
far and on the technical requirements of the system. First we need to
understand the 2 different times where the information about an instance
of a class (fact) being an event or not is needed: <br><br>* At compile
time: this is required to actually create the optimized network (including
the ObjectTypeNodes that Mike mentions). It is a must have and we can't
avoid it. The best way to do that IMO is using a specific declarative
statement in the rules files. I'm thinking about either an "import event
x.y.z.Event" statement, or a specific "declare event x.y.z.Event". This is
pure syntax to let the engine know what is an event and what is not, at
rulebase compilation time. If most users think a syntax like "I want to
declare that the x.y.z.Event instances are events" is more appropriate, :)
we could do it, but as it is today, I like the idea of using a simple
"event" keyword in import statements, the same way we import static
functions: <br><br>import a.b.c.Fact; // a simple fact import<br>import
function java.lang.Math.max; // a static function import<br><br>import
event x.y.z.Event; // an event import<br><br> If we were
an engine working with templates or any other type of fact that did not
allows inheritance, that would completely solve the problem. But we work
with POJOs as facts, and POJOs (being plain java) support inheritance. So:
<br><br>* At runtime: even knowing, at compile time, that x.y.z.Event is
an event, at runtime a user may assert p.q.r.AnotherClass into working
memory. Now, is p.q.r.AnotherClass an event or not? We need to determine
that at the time the first instance of p.q.r.AnotherClass is asserted into
the working memory. At this time, in runtime, we create an ObjectTypeNode
for this fact class that previously was not known by the engine. A few
options on how to determine that were discussed here: <br><br>1. Mandate
all classes that are events implement an "Event" interface. I don't like
this solution, as mentioned in a previous e-mail, because it breaks the
Drools paradigm of working with user defined domain models, without
contaminating them with drools specific code. Although, by your comments,
seems that this would be an acceptable solution. <br><br>2. Create a
separate API (something like "session.insertEvent()") to insert events
into the working memory. This would also "solve" the problem, but: <br>*
"What happens if a user uses this API to insert a class that was not
declared as event at compile time?". From a technical perspective, this
will lead to unpredictable behavior and possibly to inconsistencies in the
reasoning algorithm, specially because events do not need shadow facts
(they are supposed to be immutable). <br>* "What happens if a user uses
the regular 'session.insert()' API for a class that was declared as an
event at compile time?". Same as above with the additional problem that
the user may try to call update() or retract() for that given fact, what
is not allowed for events. Again, unpredictable behavior. <br>
My worry is that the only solution for the above 2 issues would be to
implement a verification routine that would validate if a fact asserted as
event is indeed an event according to what was declared at compile time,
and vice-versa. Note though, that this validation procedure would be
basically the same required for solution number 3 bellow, but would have
to be executed at every insert()/insertEvent() call, making it more costly
than the completely automated decision. <br><br>3. Implementing an
automated decision procedure, analyzing the class hierarchy of the
inserted fact, every time a fact of a previously unknown class is inserted
into working memory. Due to the problems presented in the previous
solutions, this is still my preferred approach. Its main drawback is the
class hierarchy analysis that is not simple to do and at the same time is
a bit heavy, but would happen only when the first fact of a previously
unknown class is inserted into working memory. <br><br>
So, we can probably implement solution (1) and (2) as options, but at this
time, I can't see how to avoid implementing support for (3). But having
(3), is it worth to have (1) and/or (2) too, or would it only confuse
users? <br><br> Thanks all for all the feedback so
far.<br><br> []s<br> Edson<br><br>
<div><span class="gmail_quote">2007/11/12, Anstis, Michael (M.) <<a href="mailto:manstis1@ford.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
manstis1@ford.com</a>>:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">Hi
Felipe,</font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">I
recall Edson saying that "Event" classes need to be ascertained at
(RETE) compilation time - which, I think, rules out the
API addition. </font></span><span><font color="#0000ff" face="Arial" size="2">I was hoping Edson, time permitting, would explain how
declarative (fact-centric class) imports currently work to generate
an ObjectTypeNode and therefore to understand how his proposal to create
cached ObjectTypeConf instances for Event-centric classes compares. My
reasoning being that if the process is similar the new event stuff
should be no different; simply having two ObjectTypeNodes - one for
Events and another for Facts. See attached. </font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">It's
quite possible our exchanges have given Edson time to come to his own
conclusion and the solution is now being coded! </font></span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">With
kind regards,</font> </span></div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font color="#0000ff" face="Arial" size="2">Mike</font></span></div><br>
<blockquote dir="ltr" style="margin-right: 0px;">
<div dir="ltr" align="left" lang="en-us">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev-bounces@lists.jboss.org</a> [mailto:
<a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev-bounces@lists.jboss.org</a>] <b>On Behalf Of
</b>Felipe Piccolini<br><b>Sent:</b> 12 November 2007
13:25<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>Well,
<div><br></div>
<div> IMHO for the experience I have I suggest to implement both
solutions:</div>
<div><span style="white-space: pre;"></span>-an API insertEvet() so the
user can implement the mechanism to manage </div>
<div>their rules knowing when a fact is an event or not.</div>
<div><span style="white-space: pre;"></span>-an Interface Event so when
the user cant manage the flow asserting facts, when</div>
<div>he cant know when a fact is or not an event, then maybe he can
wrap some facts on this </div>
<div>interface and the API insert() internaly can check if the fact is
an event or not and call insertEvent if</div>
<div>necesary.</div>
<div><br></div>
<div>:)</div>
<div><br>
<div>
<div>On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote: </div><br>
<blockquote type="cite">
<div style="margin: 0px;">Here's my 2 cents - as a non-contributor to
Drools codebase ;-)</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">You could add insertEventFactTypeThingie to
the API? Then you need just</div>
<div style="margin: 0px;">check that the class has been declared as
an event in the DRL similar to</div>
<div style="margin: 0px;">what must already happen for normal DRL
imports. I personally don't have</div>
<div style="margin: 0px;">issue with implementing a marker interface
(this is what frameworks like</div>
<div style="margin: 0px;">Hibernate, EJB3 and Spring etc have been
imposing for years). What "wiring"</div>
<div style="margin: 0px;">does the POJO need to become an Event for
use in Drools? Are you trying to</div>
<div style="margin: 0px;">internalise too much at the risk of making
the event mechanism inflexible?</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Cheers,</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Mike</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">-----Original Message-----</div>
<div style="margin: 0px;">From: <a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev-bounces@lists.jboss.org</a></div>
<div style="margin: 0px;">[<a href="mailto:rules-dev-bounces@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mailto:rules-dev-bounces@lists.jboss.org </a>] On
Behalf Of Matthias</div>
<div style="margin: 0px;">Sent: 08 November 2007 13:09</div>
<div style="margin: 0px;">To: <a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a></div>
<div style="margin: 0px;">Subject: Re: [rules-dev] Determining if a
class is an event or not</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Edson Tirelli <tirelli <at> <a href="http://post.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">post.com</a>> writes:</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<blockquote type="cite">
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;"><span> </span>All,
<span> </span>I reached a point where I need to make a
design decision and</div></blockquote>
<div style="margin: 0px;">would</div>
<div style="margin: 0px;">like your opinion about it. <span>
</span>Imagine the following scenario: <span> </span>A user
has a</div>
<div style="margin: 0px;">domain model like this:package a.b.c</div>
<blockquote type="cite">
<div style="margin: 0px;">;public interface Event { ... }package
x.y.z;public class MyEvent </div></blockquote>
<div style="margin: 0px;">implements</div>
<div style="margin: 0px;">a.b.c.Event {...} <span> </span>Then,
in his DRL file he writes:package p.q.r;import</div>
<div style="margin: 0px;">event </div>
<div style="margin: 0px;">a.b.c.*;<span> </span>rule
Xwhen</div>
<blockquote type="cite">
<div style="margin: 0px;"><span> </span>Event( ...
)then<span> </span>...end <span> </span>So, it
is clear that a.b.c.Event should</div></blockquote>
<div style="margin: 0px;">be</div>
<div style="margin: 0px;">handled as an event by the engine.
<span> </span>At runtime, the user asserts an object </div>
<div style="margin: 0px;">of</div>
<div style="margin: 0px;">the class x.y.z.MyEvent into the working
memory. Seems clear to me (and</div>
<div style="margin: 0px;">probably</div>
<div style="margin: 0px;">to the user) that MyEvent should be handled
as an event, since by DRL</div>
<div style="margin: 0px;">semantics,<span> </span></div>
<blockquote type="cite">
<div style="margin: 0px;">a.b.c.* are all events, and by OO class
hierarchy concept, since </div></blockquote>
<div style="margin: 0px;">a.b.c.Event</div>
<div style="margin: 0px;">is an event, x.y.z.MyEvent is an event too.
<span> </span>My question is: how the engine</div>
<div style="margin: 0px;">knows that MyEvent is an event, since it
only has the x.y.z.MyEvent</div>
<blockquote type="cite">
<div style="margin: 0px;"><span> </span>class as input?
<span> </span>The only answer I have is that when the first
MyEvent </div></blockquote>
<div style="margin: 0px;">instance is asserted into the working
memory, we must get the class name and</div>
<div style="margin: 0px;">iterate over all event import declarations
checking for a match. In case no </div>
<div style="margin: 0px;">one</div>
<div style="margin: 0px;">is found, we need to repeat the process for
each interface and each class up</div>
<div style="margin: 0px;">in</div>
<div style="margin: 0px;">the MyEvent hierarchy. Once this process is
complete, we cache the results</div>
<div style="margin: 0px;">in</div>
<div style="margin: 0px;">the
ObjectTypeConf.<span> </span></div>
<blockquote type="cite">
<div style="margin: 0px;"><span> </span>This may be a
quite heavy process to be executed each time a fact of
a</div></blockquote>
<div style="margin: 0px;">different class is asserted in the working
memory for the first time, but I </div>
<div style="margin: 0px;">can't think a different user-friendly way
to solve the question.</div>
<blockquote type="cite">
<div style="margin: 0px;"><span> </span>The
alternatives would be intrusive, IMO, breaking the drools premise
</div></blockquote>
<div style="margin: 0px;">to</div>
<div style="margin: 0px;">work with user-defined POJOs as facts: use
anotations to annotate classes</div>
<div style="margin: 0px;">that</div>
<div style="margin: 0px;">are events, or mandate users implement a
specific interface for events.</div>
<blockquote type="cite">
<div style="margin: 0px;"><span> </span>Any better
idea?<span> </span>[]s<span>
</span>Edson<span> </span>-- <span>
</span>Edson Tirelli<span> </span>Software</div></blockquote>
<div style="margin: 0px;">Engineer</div>
<div style="margin: 0px;">- JBoss Rules Core Developer<span>
</span>Office: +55 11 3529-6000<span> </span>Mobile: +55
11</div>
<div style="margin: 0px;">9287-5646</div>
<blockquote type="cite">
<div style="margin: 0px;"><span> </span>JBoss, a division of
Red Hat<span> </span><at><span> </span><a href="http://www.jboss.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.jboss.com</a></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">_______________________________________________</div>
<div style="margin: 0px;">rules-dev mailing list</div>
<div style="margin: 0px;">rules-dev <at> <a href="http://lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">lists.jboss.org</a></div>
<div style="margin: 0px;"><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-dev
</a></div>
<div style="margin: 0px; min-height: 14px;"><br></div></blockquote>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Edson,</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">I got your striving not to mandate users
implement a specific interface for</div>
<div style="margin: 0px;">events. However, why not at least
introducing an empty event interface (i.e.</div>
<div style="margin: 0px;">a</div>
<div style="margin: 0px;">marker interface, similar to the
Serializable interface in Java) the </div>
<div style="margin: 0px;">user-defined event class(es) have to
implement? This way, when inserting a</div>
<div style="margin: 0px;">MyEvent instance, you can simply check
whether it implements the event </div>
<div style="margin: 0px;">interface</div>
<div style="margin: 0px;">(by means of 'instanceof'). Moreover, while
parsing the import statements of</div>
<div style="margin: 0px;">a</div>
<div style="margin: 0px;">rule file, it enables you to double-check
whether all the "event imports"</div>
<div style="margin: 0px;">really</div>
<div style="margin: 0px;">refer to classes implementing the (empty)
event interface. </div>
<div style="margin: 0px;">In this regard, for me another question
raises: Without making any</div>
<div style="margin: 0px;">restrictions</div>
<div style="margin: 0px;">on the structure for a user defined event
class, how do you make sure it has </div>
<div style="margin: 0px;">all</div>
<div style="margin: 0px;">the<span> </span>required attributes
of an event (which in my opinion must be a</div>
<div style="margin: 0px;">timestamp,</div>
<div style="margin: 0px;">at least) and how do you access them
(necessary for temporal relationships)?</div>
<div style="margin: 0px;">Having said this, in my opinion defining an
empty event interface may not be</div>
<div style="margin: 0px;">sufficient; in addition, it must force the
user to implement a method</div>
<div style="margin: 0px;">returning</div>
<div style="margin: 0px;">the event's occurrence date (i.e. the
timestamp) at least... Or how would </div>
<div style="margin: 0px;">you</div>
<div style="margin: 0px;">handle this issue?</div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">Matthias<span> </span></div>
<div style="margin: 0px; min-height: 14px;"><br></div>
<div style="margin: 0px;">_______________________________________________</div>
<div style="margin: 0px;">rules-dev mailing list</div>
<div style="margin: 0px;"><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a></div>
<div style="margin: 0px;"><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-dev
</a></div>
<div style="margin: 0px;">_______________________________________________</div>
<div style="margin: 0px;">rules-dev mailing list</div>
<div style="margin: 0px;"><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a></div>
<div style="margin: 0px;"><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-dev
</a></div></blockquote></div><br>
<div><span style="word-spacing: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; font-size-adjust: none; font-stretch: normal; border-spacing: 0px;">
<div><span style="text-decoration: underline;"><span>
</span></span>
<div><font size="3"><span style="font-size: 13px;"><b style="font-weight: bold; font-size: 13px;"><span style="font-weight: bold; font-size: 13px;">Felipe Piccolini
M.</span></b></span></font></div>
<div><a href="mailto:felipe.piccolini@bluesoft.cl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"><span style="color: rgb(0, 0, 238);">felipe.piccolini@bluesoft.cl</span></a></div><br></div>
<div><br></div><br></span></div><br></div></span></div></blockquote></div><br>_______________________________________________<br>rules-dev
mailing list<br><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.jboss.com</a>
<div style="margin: 0px;">_______________________________________________
</div>
<div style="margin: 0px;">rules-dev mailing list</div>
<div style="margin: 0px;"><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org </a></div>
<div style="margin: 0px;"><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</div></blockquote></div><br>
<div><span style="word-spacing: 0px; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; font-size: 12px; line-height: normal; font-size-adjust: none; font-stretch: normal; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; border-spacing: 0px;">
<div><span style="text-decoration: underline;"><span>
</span></span>
<div><font size="3"><span style="font-size: 13px;"><b style="font-weight: bold; font-size: 13px;"><span style="font-weight: bold; font-size: 13px;">Felipe Piccolini
M.</span></b></span></font></div>
<div><a href="mailto:felipe.piccolini@bluesoft.cl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"><span style="color: rgb(0, 0, 238);">felipe.piccolini@bluesoft.cl</span></a></div><br></div>
<div><br></div><br></span></div><br></div></span></div></div><br>_______________________________________________<br>rules-dev
mailing list <br><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><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 href="http://www.jboss.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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>