<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Personally I don't like the idea of a Map as a model as it has no type,
so straight away you lose object level descrimination. Also a Map is
not declarative in defining what it is you are reasoning over. It's a
hack to get over the limitations of the current environment.<br>
<br>
In the engine we have something called FactTemplats, which we do not
currently document - it's a hidden feature. These work much less Jess
Deftemplates, and where infact made so that we could support a
Jess/clips. The implementation is basically an array and uses name
tokenising to get access. i.e. you write person.name == "Godmar" and we
rewrite it as person.setField( 0, "Godmar" ). Although we haven't yet
got the rewritting part done so currently you have to manually do the
above, or make it lookup the position each time with person.setField(
"name", "Godmar" ). These FactTemplates can be reasoned over in the LHS
just like pojos.<br>
<br>
However I'm not currently happy with the solution and thinking instead
of going down the route of runtime bean generation. This would allow
you to define models at runtime, without caring about the underlying
implementation, and still give us pojos to work with and also provides
more performance. further to this we really want to do our model
implementation with ontology support. So that users can supply static
and dynamic constraints to the properties they define on a class.<br>
<br>
It's currently touch and go if either of these will make it into 5.0,
I'm really hoping that we can do the later solution, but we currently
have many more priorities :(<br>
<br>
<br>
Mark<br>
Godmar Back wrote:
<blockquote
cite="mid:719dced30802200953r5493da6dh6b15d028e102a9a0@mail.gmail.com"
type="cite">
<pre wrap="">On Feb 20, 2008 12:30 PM, Edson Tirelli <a class="moz-txt-link-rfc2396E" href="mailto:tirelli@post.com"><tirelli@post.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Godmar,
Shadow Facts are a necessary evil in current version. Basically what they
do is keep the working memory consistent in face of attribute changes on the
facts, that may happen both internally and externally to the working memory.
Our implementation to shadow facts is a lazy proxy that caches the
values until a safe point to synchronize the actual attribute value with the
one seen by the engine.
So, the question is: given an object:
(Map) fact
How can we create an identical copy of it (shadow), if there is no
"clone" operation?
</pre>
</blockquote>
<pre wrap=""><!---->
Can you explain why you require the use of "clone()"?
Cloning a map is otherwise easy - it's also referred to as a "shallow
copy" -- HashMap's HashMap(Map) constructor will do it.
<a class="moz-txt-link-freetext" href="http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html#HashMap(java.util.Map)">http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html#HashMap(java.util.Map)</a>
I know you know that, so explain what necessitates the use of clone().
</pre>
<blockquote type="cite">
<pre wrap="">More than that, the shadow must be a subclass of it.
</pre>
</blockquote>
<pre wrap=""><!---->
java.util.HashMap is a subclass of Map.
</pre>
<blockquote type="cite">
<pre wrap=""> Most Collection and Map implementations have a single parameter
constructor that allows us to do:
proxy = (ShadowProxy) this.shadowClass.getConstructor( new Class[]{cls}
).newInstance( new Object[]{fact} );
But the SingletonMap you were using does not accept that constructor.
So, one way is to explicit check if the fact is a SingletonMap and handle it
accordingly, but that is a specific class hack... is there any general
solution we can use?
</pre>
</blockquote>
<pre wrap=""><!---->
Forget about the SingletonMap. That was just one of the many things I
tried and failed.
Fundamentally, I would like Drools to process facts that were obtained
from real-world sources, and these facts have properties I do not know
in advance. Therefore, I cannot use beans (or using beans would be
highly inconvenient since it will require changes to Java code
whenever I'm referring to a new property, something I'd rather avoid.)
- Godmar
</pre>
<blockquote type="cite">
<pre wrap=""> []s
Edson
2008/2/20, Godmar Back <a class="moz-txt-link-rfc2396E" href="mailto:godmar@gmail.com"><godmar@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">I don't really understand what you mean by "shadow". What is the
purpose of such shadowing. Mark's email implies that it has to do with
concurrency protection; it's not clear what that means.
In my view, whatever purpose you pursue with "shadowing", it does not
justify treating beans and maps differently.
Your example of class Person shows that. If a person has two
attributes, name and age, then this is equivalent to a map with two
keys 'name' and 'age'.
Here's the mapping:
p.getName() corresponds to m["name"]
p.getAge() corresponds to m["age"]
and setName/setAge accordingly.
Mathematically, a bean is an associative array with a fixed set of
keys (called "properties") that map to values. For all practical
purposes, that is the same as a map. There's no reason to treat them
differently. Wherever you'd do "getXXX()" with a bean you'd do
.get("XXX") with a map.
- Godmar
On Feb 20, 2008 11:25 AM, Edson Tirelli <a class="moz-txt-link-rfc2396E" href="mailto:tirelli@post.com"><tirelli@post.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Ok, let me show one example. Imagine the class Person, with 2
</pre>
</blockquote>
</blockquote>
<pre wrap="">attributes
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">(name and age) and the corresponding getter/setters.
What are the data for that fact that must be shadowed? easy answer:
</pre>
</blockquote>
</blockquote>
<pre wrap="">just
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">shadow all getXXX() methods (getName and getAge).
Now, take a Map. What is the data that must be shadowed?
So, we do our best to work with facts that don't follow the javabean
spec, but collections and maps are a complicated beast. Again, if you
</pre>
</blockquote>
</blockquote>
<pre wrap="">have
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">suggestions on how to improve the current support we provide for them,
please share with us.
[]s
Edson
2008/2/20, Godmar Back <a class="moz-txt-link-rfc2396E" href="mailto:godmar@gmail.com"><godmar@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">On Feb 20, 2008 9:23 AM, Edson Tirelli <a class="moz-txt-link-rfc2396E" href="mailto:tirelli@post.com"><tirelli@post.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Godmar,
Short answer: collection/maps objects are not javabeans.
</pre>
</blockquote>
<pre wrap="">Explain why this is a problem.
What is it about JavaBeans that your algorithm relies upon? Is it the
fact that the set of properties remains fixed and can be determined at
(fact) insertion time via reflection?
Otherwise, I do not see any conceptual difference between a map and a
</pre>
</blockquote>
<pre wrap="">bean.
</pre>
<blockquote type="cite">
<pre wrap="">If that is the difference, then please allow maps with an immutable
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">key
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">set.
</pre>
<blockquote type="cite">
<pre wrap="">- Godmar
</pre>
<blockquote type="cite">
<pre wrap=""> Long answer: collection/maps must be shadowed to ensure
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">consistency
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">during execution, but how can we shadow the data if it is not
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">exposed in
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">a
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">default, spec manner, as in javabeans? The algorithm we have in
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">place
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">right
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">now is bellow. As you can see, it is a weak algo, but was the best I
</pre>
</blockquote>
</blockquote>
<pre wrap="">could
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">come up at that time. If you have any suggestions on how to improve
</pre>
</blockquote>
</blockquote>
<pre wrap="">that, I
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">appreciate.
public Object getShadow(final Object fact) throws
</pre>
</blockquote>
</blockquote>
<pre wrap="">RuntimeDroolsException
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">{
ShadowProxy proxy = null;
if ( isShadowEnabled() ) {
try {
if ( Collection.class.isAssignableFrom(
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">this.shadowClass
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">|| Map.class.isAssignableFrom( this.shadowClass ) ) {
// if it is a collection, try to instantiate
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">using
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">constructor
try {
proxy = (ShadowProxy)
this.shadowClass.getConstructor( new Class[]{cls} ).newInstance( new
Object[]{fact} );
} catch ( Exception e ) {
// not possible to instantiate using
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">constructor
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> }
}
if ( proxy == null ) {
if ( this.instantiator == null ) {
this.setInstantiator();
}
proxy = (ShadowProxy)
</pre>
</blockquote>
</blockquote>
<pre wrap="">this.instantiator.newInstance();
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> }
proxy.setShadowedObject( fact );
} catch ( final Exception e ) {
System.out.println( "shadow: " +proxy.getClass() +
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">":" +
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">fact.getClass() );
throw new RuntimeDroolsException( "Error creating
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">shadow
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">fact for object: " + fact,
e );
}
}
return proxy;
}
[]s
Edson
2008/2/19, Godmar Back <a class="moz-txt-link-rfc2396E" href="mailto:godmar@gmail.com"><godmar@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">As a general comment, the examples for which I find Drools failing
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">are
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">not the actual examples for which my application is failing. It's
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">just
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">the smallest test case I was able to eliminate.
I'm now a bit concerned about your comment that Maps and
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">Collections
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">aren't well-defined as Facts. I am planning to make extensive use
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">of
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">them (that's also why I'd prefer to use the MVEL dialect, because
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">in
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Java I cannot do this without creating Bean wrappers.)
Could you elaborate what makes the semantics not "well-defined".
I'm specifically concerned with immutable maps (such as the one
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">that
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">would have been returned by Collections.singletonMap), and with
collections of maps (such as those obtained via a "from"..."
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">clause).
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I need to insert immutable maps as facts; I understand that the
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">items
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">returned by "from" aren't inserted as facts.
- Godmar
On Feb 19, 2008 3:11 PM, Edson Tirelli <a class="moz-txt-link-rfc2396E" href="mailto:tirelli@post.com"><tirelli@post.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Drools tries to create the ShadowProxy. The reason is that it
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">does
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">not
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">know about the implementation... it just knows it is a Map and
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">as
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">so, it
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">must be shadowed. Problem is that SingletonMap is either final
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">or
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">does
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">not
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">have a default constructor.
My recommendation, besides opening a JIRA for this, is avoid
</pre>
</blockquote>
</blockquote>
<pre wrap="">inserting
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">collections/maps directly as facts. The semantic for such facts
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">is
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">not
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">clearly defined and it may cause undesired behavior.
[]s
Edson
2008/2/19, Godmar Back <a class="moz-txt-link-rfc2396E" href="mailto:godmar@gmail.com"><godmar@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">
Hi,
usings Drools 4.0.4 and MVEL 1.4, this simple rule:
---
package test;
import java.util.Collections;
dialect "mvel"
rule "Rule #1"
when
then
insert(Collections.singletonMap("content", "hello"));
end
--
produces:
java.lang.IllegalAccessError: class
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.shadow.java.util.Collections$SingletonMapShadowProxy
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">cannot
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">access its superclass java.util.Collections$SingletonMap
at java.lang.ClassLoader.defineClass1(Native Method)
at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">java.lang.ClassLoader.defineClass(ClassLoader.java:620)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">java.lang.ClassLoader.loadClass(ClassLoader.java:251)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.reteoo.Rete$ClassObjectTypeConf.loadOrGenerateProxy(Rete.java:547)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.reteoo.Rete$ClassObjectTypeConf.defineShadowProxyData(Rete.java:494)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
<pre wrap="">org.drools.reteoo.Rete$ClassObjectTypeConf.<init>(Rete.java:461)
</pre>
<blockquote type="cite">
<pre wrap=""> at org.drools.reteoo.Rete.assertObject(Rete.java:152)
at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:909)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:67)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> at
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:61)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
It's not clear to me why Drools creates Proxies for such
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">classes
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">as
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">java.util.Collections, or does MVEL do it?
- Godmar
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<pre wrap="">
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ <a class="moz-txt-link-abbreviated" href="http://www.jboss.com">www.jboss.com</a>
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<pre wrap="">
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ <a class="moz-txt-link-abbreviated" href="http://www.jboss.com">www.jboss.com</a>
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<pre wrap="">
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ <a class="moz-txt-link-abbreviated" href="http://www.jboss.com">www.jboss.com</a>
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<pre wrap="">_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<pre wrap="">
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ <a class="moz-txt-link-abbreviated" href="http://www.jboss.com">www.jboss.com</a>
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<br>
</body>
</html>