Re: [rules-users] Mvel compilation error
This is not a compilation error, it's a runtime error. It means you're passing a wrong type. For instance, you may do: f.m(x) where method m is declared to take a type T, but you pass an object x of type S which is not a subtype of T. To debug this, examine the arguments in the section of code. Also, insert statements such as: if (!(x instanceof T)) System.err.println() before the call to f or use asserts. - Godmar On Fri, Jul 18, 2008 at 10:57 AM, Edson Tirelli [EMAIL PROTECTED] wrote: Hey John, I know it is difficult, but we need some way to reproduce... can you isolate a few rules and run them in a loop trying to force the exception? 2008/7/17 John Squire [EMAIL PROTECTED]: Hi All, We are intermittently getting mvel compilation errors with the following: Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.mvel.optimizers.impl.refl.MethodAccessor.getValue(MethodAccessor.java:61) ... 148 more The rules compile ok and the application will run normally (rules processing successfully) for a few days then this error will occur. Tried to replicate but once the application is restarted the last action before the failure is repeated and always processes successfully. Any help would be appreciated. Regards JS ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss, a division of 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
[rules-users] what is the current drools release?
What's the most current drools release? There's discussion of 4.0.5 and 4.0.6 in the email below, which dates from 26-Mar-2008, but http://labs.jboss.com/drools/downloads.html lists 4.0.4 as having been released 31-Mar-2008 and does not mention 4.0.5 and 4.0.6. Thanks. - Godmar On Wed, Mar 26, 2008 at 9:20 AM, Mark Proctor [EMAIL PROTECTED] wrote: Sounds like when the MVEL author release 1.2.24 he didn't do a valid pom.xml - I'll let him know. There is also another problem with the 4.0.5 and the MVEL eclipse configuration - see email thread below. I'm going to push for a 4.0.6 release next week, to address this. 1.2.25 or 1.2.24 is fine - as long as you always use the same version for everything, they aren't serialisation compatible. Sorry. Eric Miles wrote: I am attempting to build a project using Maven2 with Drools 4.0.5 and JDK 1.4. The MVEL dependency was downloaded and I'm getting an error with it's pom: mvel-1.2.24-java1.4.pom 3/26/08 8:51:09 AM EDT: Parsing error /home/emiles/.m2/repository/org/mvel/mvel/1.2.24-java1.4/mvel-1.2.24-java1.4.pom; org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name /pakaging must match start tag name packaging from line 6 (position: TEXT seen ...packagingjar/pakaging... @6:30) 3/26/08 8:51:09 AM EDT: Unable to read smarttime/pom.xml; org.eclipse.core.runtime.CoreException: Parsing error /home/emiles/.m2/repository/org/mvel/mvel/1.2.24-java1.4/mvel-1.2.24-java1.4.pom; org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name /pakaging must match start tag name packaging from line 6 (position: TEXT seen ...packagingjar/pakaging... @6:30) I excluded version 1.2.24 and used 1.2.25 instead, which fixes my build path errors. Is this version okay to use with Drools 4.0.5? Thanks! Eric The mvel release is screwed up. dependency groupIdorg.mvel/groupId artifactIdmvel/artifactId version1.2.24-java1.4/version /dependency Our mvel, for the 1.4 backport, has always been called mve14 - as we've done the releases ourselves in the past. dependency groupIdorg.mvel/groupId artifactIdmvel14/artifactId version1.2.21/version /dependency So now when eclipse does the version stripping it includes mvel.jar and not mvel14.jar, leaving it screwed. Mark ___ 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] IllegalAccessError in shadow classes
On Feb 20, 2008 9:23 AM, Edson Tirelli [EMAIL PROTECTED] wrote:
Godmar,
Short answer: collection/maps objects are not javabeans.
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 bean.
If that is the difference, then please allow maps with an immutable key set.
- Godmar
Long answer: collection/maps must be shadowed to ensure consistency
during execution, but how can we shadow the data if it is not exposed in a
default, spec manner, as in javabeans? The algorithm we have in place right
now is bellow. As you can see, it is a weak algo, but was the best I could
come up at that time. If you have any suggestions on how to improve that, I
appreciate.
public Object getShadow(final Object fact) throws RuntimeDroolsException
{
ShadowProxy proxy = null;
if ( isShadowEnabled() ) {
try {
if ( Collection.class.isAssignableFrom( this.shadowClass )
|| Map.class.isAssignableFrom( this.shadowClass ) ) {
// if it is a collection, try to instantiate using
constructor
try {
proxy = (ShadowProxy)
this.shadowClass.getConstructor( new Class[]{cls} ).newInstance( new
Object[]{fact} );
} catch ( Exception e ) {
// not possible to instantiate using constructor
}
}
if ( proxy == null ) {
if ( this.instantiator == null ) {
this.setInstantiator();
}
proxy = (ShadowProxy) this.instantiator.newInstance();
}
proxy.setShadowedObject( fact );
} catch ( final Exception e ) {
System.out.println( shadow: +proxy.getClass() + : +
fact.getClass() );
throw new RuntimeDroolsException( Error creating shadow
fact for object: + fact,
e );
}
}
return proxy;
}
[]s
Edson
2008/2/19, Godmar Back [EMAIL PROTECTED]:
As a general comment, the examples for which I find Drools failing are
not the actual examples for which my application is failing. It's just
the smallest test case I was able to eliminate.
I'm now a bit concerned about your comment that Maps and Collections
aren't well-defined as Facts. I am planning to make extensive use of
them (that's also why I'd prefer to use the MVEL dialect, because in
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 that
would have been returned by Collections.singletonMap), and with
collections of maps (such as those obtained via a from... clause).
I need to insert immutable maps as facts; I understand that the items
returned by from aren't inserted as facts.
- Godmar
On Feb 19, 2008 3:11 PM, Edson Tirelli [EMAIL PROTECTED] wrote:
Drools tries to create the ShadowProxy. The reason is that it does
not
know about the implementation... it just knows it is a Map and as so, it
must be shadowed. Problem is that SingletonMap is either final or does
not
have a default constructor.
My recommendation, besides opening a JIRA for this, is avoid
inserting
collections/maps directly as facts. The semantic for such facts is not
clearly defined and it may cause undesired behavior.
[]s
Edson
2008/2/19, Godmar Back [EMAIL PROTECTED]:
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
org.drools.shadow.java.util.Collections$SingletonMapShadowProxy cannot
access its superclass java.util.Collections$SingletonMap
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60)
at
org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.drools.reteoo.Rete$ClassObjectTypeConf.loadOrGenerateProxy(Rete.java:547)
at
org.drools.reteoo.Rete$ClassObjectTypeConf.defineShadowProxyData(Rete.java:494)
at
org.drools.reteoo.Rete$ClassObjectTypeConf.init(Rete.java:461
Re: [rules-users] IllegalAccessError in shadow classes
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 [EMAIL PROTECTED] wrote:
Ok, let me show one example. Imagine the class Person, with 2 attributes
(name and age) and the corresponding getter/setters.
What are the data for that fact that must be shadowed? easy answer: just
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 have
suggestions on how to improve the current support we provide for them,
please share with us.
[]s
Edson
2008/2/20, Godmar Back [EMAIL PROTECTED]:
On Feb 20, 2008 9:23 AM, Edson Tirelli [EMAIL PROTECTED] wrote:
Godmar,
Short answer: collection/maps objects are not javabeans.
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
bean.
If that is the difference, then please allow maps with an immutable key
set.
- Godmar
Long answer: collection/maps must be shadowed to ensure consistency
during execution, but how can we shadow the data if it is not exposed in
a
default, spec manner, as in javabeans? The algorithm we have in place
right
now is bellow. As you can see, it is a weak algo, but was the best I
could
come up at that time. If you have any suggestions on how to improve
that, I
appreciate.
public Object getShadow(final Object fact) throws
RuntimeDroolsException
{
ShadowProxy proxy = null;
if ( isShadowEnabled() ) {
try {
if ( Collection.class.isAssignableFrom( this.shadowClass
)
|| Map.class.isAssignableFrom( this.shadowClass ) ) {
// if it is a collection, try to instantiate using
constructor
try {
proxy = (ShadowProxy)
this.shadowClass.getConstructor( new Class[]{cls} ).newInstance( new
Object[]{fact} );
} catch ( Exception e ) {
// not possible to instantiate using constructor
}
}
if ( proxy == null ) {
if ( this.instantiator == null ) {
this.setInstantiator();
}
proxy = (ShadowProxy)
this.instantiator.newInstance();
}
proxy.setShadowedObject( fact );
} catch ( final Exception e ) {
System.out.println( shadow: +proxy.getClass() + : +
fact.getClass() );
throw new RuntimeDroolsException( Error creating shadow
fact for object: + fact,
e );
}
}
return proxy;
}
[]s
Edson
2008/2/19, Godmar Back [EMAIL PROTECTED]:
As a general comment, the examples for which I find Drools failing are
not the actual examples for which my application is failing. It's just
the smallest test case I was able to eliminate.
I'm now a bit concerned about your comment that Maps and Collections
aren't well-defined as Facts. I am planning to make extensive use of
them (that's also why I'd prefer to use the MVEL dialect, because in
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 that
would have been returned by Collections.singletonMap), and with
collections of maps (such as those obtained via a from... clause).
I need to insert immutable maps as facts; I understand that the items
returned by from aren't inserted as facts.
- Godmar
On Feb
Re: [rules-users] IllegalAccessError in shadow classes
On Feb 20, 2008 12:30 PM, Edson Tirelli [EMAIL PROTECTED] wrote:
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?
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html#HashMap(java.util.Map)
I know you know that, so explain what necessitates the use of clone().
More than that, the shadow must be a subclass of it.
java.util.HashMap is a subclass of Map.
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?
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
[]s
Edson
2008/2/20, Godmar Back [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] wrote:
Ok, let me show one example. Imagine the class Person, with 2
attributes
(name and age) and the corresponding getter/setters.
What are the data for that fact that must be shadowed? easy answer:
just
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
have
suggestions on how to improve the current support we provide for them,
please share with us.
[]s
Edson
2008/2/20, Godmar Back [EMAIL PROTECTED]:
On Feb 20, 2008 9:23 AM, Edson Tirelli [EMAIL PROTECTED] wrote:
Godmar,
Short answer: collection/maps objects are not javabeans.
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
bean.
If that is the difference, then please allow maps with an immutable
key
set.
- Godmar
Long answer: collection/maps must be shadowed to ensure
consistency
during execution, but how can we shadow the data if it is not
exposed in
a
default, spec manner, as in javabeans? The algorithm we have in
place
right
now is bellow. As you can see, it is a weak algo, but was the best I
could
come up at that time. If you have any suggestions on how to improve
that, I
appreciate.
public Object getShadow(final Object fact) throws
RuntimeDroolsException
{
ShadowProxy proxy = null;
if ( isShadowEnabled() ) {
try {
if ( Collection.class.isAssignableFrom
Re: [rules-users] IllegalAccessError in shadow classes
PS: I think I know where the confusion lies.
You consider maps just another kind of Java object you attempt to
treat like you would treat other objects - by examining their member
fields and methods, constructors, etc.
I was under the impression that instances of java.util.Maps would be
treated specially by your engine, i.e., as a collection of properties.
I concluded that since in the MVEL dialect you allow the use of the []
operator in a LHS. It seemed the straightforward thing to do, given
the conceptual equivalency of beans and (fixed-keyset) maps.
Maybe I should rephrase my question then. How do I work with facts for
which the set of properties is not known when I compile the Java
portions of the program in which I'm embedding my Drools rules?
- Godmar
On Wed, Feb 20, 2008 at 12:53 PM, Godmar Back [EMAIL PROTECTED] wrote:
On Feb 20, 2008 12:30 PM, Edson Tirelli [EMAIL PROTECTED] wrote:
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?
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html#HashMap(java.util.Map)
I know you know that, so explain what necessitates the use of clone().
More than that, the shadow must be a subclass of it.
java.util.HashMap is a subclass of Map.
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?
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
[]s
Edson
2008/2/20, Godmar Back [EMAIL PROTECTED]:
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 [EMAIL PROTECTED] wrote:
Ok, let me show one example. Imagine the class Person, with 2
attributes
(name and age) and the corresponding getter/setters.
What are the data for that fact that must be shadowed? easy answer:
just
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
have
suggestions on how to improve the current support we provide for them,
please share with us.
[]s
Edson
2008/2/20, Godmar Back [EMAIL PROTECTED]:
On Feb 20, 2008 9:23 AM, Edson Tirelli [EMAIL PROTECTED] wrote:
Godmar,
Short answer: collection/maps objects are not javabeans.
Explain why this is a problem.
What
Re: [rules-users] IllegalAccessError in shadow classes
I think that you *should* treat facts that implement java.util.Map differently from other facts. Ignore their concrete class and don't worry about applying your shadowing algorithm. Then, treat them as if they were beans with getXYZ() methods for each key XYZ they contain. Your reply indicates that you haven't even considered this design. I wonder why not? (It seemed so natural to me that I assumed it's what Drools *must* do. Especially considering the fact that Drools's chosen scripting language, MVEL, supports accesses to maps using a special, javascript-like syntax that allows you to verify that accesses are side-effect free.) On Wed, Feb 20, 2008 at 4:11 PM, Edson Tirelli [EMAIL PROTECTED] wrote: A blog I wrote a long time ago about dynamically generated beans: http://blog.athico.com/2006/12/dynamically-generated-class-beans-as.html I'm aware that I can generate beans - dynamically or statically, but that is exactly the hassle I had hoped to avoid. (And, quite frankly, it's not something I should have to go through when using a framework such as Drools.) Will the issue disappear in a future, shadowless version of your engine? To what degree will this version depend on facts being conforming Java beans? - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] IllegalAccessError in shadow classes
A general solution with arbitrary, user-defined fact types such as the one you propose would indeed be nice, but as you say requires significant implementation effort. Simply supporting maps in addition to beans should be simple (in a sound and properly encapsulated design) and may give a significant portion of the benefits, considering that a) many Java libraries already use standard collection classes centered around maps and b) even if they don't, they can be easily converted into Maps without requiring tedious code generation in the way your current bean-only approach does. My 2c. - Godmar On Wed, Feb 20, 2008 at 5:39 PM, Edson Tirelli [EMAIL PROTECTED] wrote: Godmar, Ok, now I understood what you mean. This ability to use Maps as a special type of facts requires the implementation of what we call pluggable fact types. It is something we wanted to have for ages, but it is not implemented yet. Unfortunately it is not as easy as it may appear, but definitively it is a must have for the future, specially as we move to the ontology space. You are right to think that this will give us another level of expressive power. Among several other advantages, it would allow the the user instead of writing patterns like: Map( this.factType == SomeFactType, ... ) Where factType is a key in the Map, to simply write rules: SomeFactType( ... ) More than that, once we have such feature, we can directly use any structure mappable into a Java class as a fact, like Grrovy/Jython/Whatever beans, CSV files, XML documents, etc. So, it is REALLY powerful and really cool! Our only limitation is indeed (wo)man power... :) Seriously speaking, we already have pluggable dialects, pluggable evaluators and an almost pluggable extractor framework. All of them are pre-reqs for the pluggable fact types, but we did not reached that point yet. Talking about the project, the team is now committed to deliver support to CEP applications (including temporal reasoning and stream management), support to higher levels of ruleflow and process modeling, improving the whole BRMS and repository tools, plus we have Master Degree and PhD students working on Machine Learning, Decision Trees, Uncertainty Reasoning, Temporal Reasoning and Rulebase Static Analysis. As you can see there is a LOT on our plate, so if anyone wants to step up and help us accelerate the development of pluggable fact types, it is more than welcome. ANYONE up to the task? :) Regarding your question about the removal of shadow fact, yes, it is scheduled for the next major release in a few months time. Although, it is import to remember that you can already disable shadow facts, just by following some requirements. I will write another e-mail about that. []s Edson 2008/2/20, Godmar Back [EMAIL PROTECTED]: I think that you *should* treat facts that implement java.util.Map differently from other facts. Ignore their concrete class and don't worry about applying your shadowing algorithm. Then, treat them as if they were beans with getXYZ() methods for each key XYZ they contain. Your reply indicates that you haven't even considered this design. I wonder why not? (It seemed so natural to me that I assumed it's what Drools *must* do. Especially considering the fact that Drools's chosen scripting language, MVEL, supports accesses to maps using a special, javascript-like syntax that allows you to verify that accesses are side-effect free.) On Wed, Feb 20, 2008 at 4:11 PM, Edson Tirelli [EMAIL PROTECTED] wrote: A blog I wrote a long time ago about dynamically generated beans: http://blog.athico.com/2006/12/dynamically-generated-class-beans-as.html I'm aware that I can generate beans - dynamically or statically, but that is exactly the hassle I had hoped to avoid. (And, quite frankly, it's not something I should have to go through when using a framework such as Drools.) Will the issue disappear in a future, shadowless version of your engine? To what degree will this version depend on facts being conforming Java beans? - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of 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] IllegalAccessError in shadow classes
Now that I read Ed's post, I realize I can simply turn shadowing off.
I don't use facts whose attributes change (*).
- Godmar
(*) This probably shows my ignorance here - I freely admit the last
time I used expert systems before the current exercise was during an
AI class in college in the 90s - but why do systems such as Drools
support modifiable facts in the first place? If facts become invalid,
they should be retracted and new facts be provided, but why support
changing a fact literally after the fact, if you pardon the pun?
Ed's example with person.likes changing from cheese to chocolate is
particularly telling, because such as change would - in common
parlance - be considered a change of opinion rather than a changing of
facts.
On Wed, Feb 20, 2008 at 9:40 PM, Mark Proctor [EMAIL PROTECTED] wrote:
If you want to use FactTemplates as a temporary, unsupported approach, feel
free. There are unit tests that show how this work.
Btw when you use MVEL notation to access nested objects, like you do with a
Map, we just re-write it as an eval. This means you won't get any of the
indexing performance. You can still get indexing if you represent your facts
with FactTemplates.
Mark
Mark Proctor wrote:
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.
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.
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.
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 :(
Mark
Godmar Back wrote:
On Feb 20, 2008 12:30 PM, Edson Tirelli [EMAIL PROTECTED] wrote:
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?
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html#HashMap(java.util.Map)
I know you know that, so explain what necessitates the use of clone().
More than that, the shadow must be a subclass of it.
java.util.HashMap is a subclass of Map.
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?
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
[]s
Edson
2008/2/20, Godmar Back [EMAIL PROTECTED]:
I don't really understand what you mean by shadow. What is the
purpose of such shadowing. Mark's
Re: [rules-users] IllegalAccessError in shadow classes
On Wed, Feb 20, 2008 at 9:40 PM, Mark Proctor [EMAIL PROTECTED] wrote:
Btw when you use MVEL notation to access nested objects, like you do with a
Map, we just re-write it as an eval. This means you won't get any of the
indexing performance. You can still get indexing if you represent your facts
with FactTemplates.
FWIW - I used MVEL notation to bypass the restriction that function
calls aren't allowed on LHS, not for indexing reasons, that is,
e[prop] instead of e.get(prop) which to Drools looks like a
function call with a potential side effects. I had hoped to avoid
turning my maps into POJOs/beans; additionally, one of my goals is to
keep my rule base easily readable (thus avoid the explicit use of
eval()).
Regarding your other comment about supporting Maps are special fact
types - you mention that you'd lose type information - that's not
necessarily the case if you postulate that only maps whose key set and
value types don't change past insertion. In that case, you can find
the type via runtime reflection on the concrete objects being carried
in the map. Overall, though, I agree that it's probably only a
stopgap measure and a better design is required. See also my other
comment about what uses Drools should provide for IMO.
- Godmar
Mark
Mark Proctor wrote:
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.
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.
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.
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 :(
Mark
Godmar Back wrote:
On Feb 20, 2008 12:30 PM, Edson Tirelli [EMAIL PROTECTED] wrote:
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?
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.
http://java.sun.com/j2se/1.4.2/docs/api/java/util/HashMap.html#HashMap(java.util.Map)
I know you know that, so explain what necessitates the use of clone().
More than that, the shadow must be a subclass of it.
java.util.HashMap is a subclass of Map.
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?
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
[]s
Edson
2008/2/20, Godmar Back [EMAIL PROTECTED]:
I don't really understand what you
[rules-users] unable to resolve token in simple mvel RHS
Hi, with Drools 4.0.4 and MVEL 1.4, simple RHS like this one fail for me: --- package test; dialect mvel rule Rule #1 when then System.out.println(now computing 1+1...); Integer two = new Integer(2); System.out.println(two); end --- now computing 1+1... org.mvel.CompileException: unable to resolve property: two at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:288) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109) at org.mvel.ast.ContextDeepPropertyNode.getReducedValueAccelerated(ContextDeepPropertyNode.java:26) at org.mvel.ast.PropertyASTNode.initializePropertyNode(PropertyASTNode.java:123) at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:26) at org.mvel.ExecutableAccessor.getValue(ExecutableAccessor.java:45) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:521) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:260) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109) at org.mvel.ast.LiteralDeepPropertyNode.getReducedValueAccelerated(LiteralDeepPropertyNode.java:28) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111) at org.mvel.MVEL.executeExpression(MVEL.java:235) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) at org.libx.autodetect.DroolsDriver$Host.fireAllRules(DroolsDriver.java:63) at org.libx.autodetect.DroolsDriver.main(DroolsDriver.java:136) Caused by: org.mvel.PropertyAccessException: unable to resolve property: two at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:382) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:257) ... 19 more org.mvel.CompileException: unable to resolve token: two at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:297) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109) at org.mvel.ast.LiteralDeepPropertyNode.getReducedValueAccelerated(LiteralDeepPropertyNode.java:28) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111) at org.mvel.MVEL.executeExpression(MVEL.java:235) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) at org.libx.autodetect.DroolsDriver$Host.fireAllRules(DroolsDriver.java:63) at org.libx.autodetect.DroolsDriver.main(DroolsDriver.java:136) Caused by: org.mvel.UnresolveablePropertyException: unable to resolve token: two at org.mvel.ast.PropertyASTNode.initializePropertyNode(PropertyASTNode.java:127) at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:26) at org.mvel.ExecutableAccessor.getValue(ExecutableAccessor.java:45) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:521) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:260) ... 12 more Caused by: org.mvel.CompileException: unable to resolve property: two at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:288) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109) at org.mvel.ast.ContextDeepPropertyNode.getReducedValueAccelerated(ContextDeepPropertyNode.java:26) at org.mvel.ast.PropertyASTNode.initializePropertyNode(PropertyASTNode.java:123) ... 16 more Caused by: org.mvel.PropertyAccessException: unable to resolve property: two at
[rules-users] IllegalAccessError in shadow classes
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 org.drools.shadow.java.util.Collections$SingletonMapShadowProxy cannot access its superclass java.util.Collections$SingletonMap at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60) at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.drools.reteoo.Rete$ClassObjectTypeConf.loadOrGenerateProxy(Rete.java:547) at org.drools.reteoo.Rete$ClassObjectTypeConf.defineShadowProxyData(Rete.java:494) at org.drools.reteoo.Rete$ClassObjectTypeConf.init(Rete.java:461) at org.drools.reteoo.Rete.assertObject(Rete.java:152) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:909) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881) at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:67) at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:61) It's not clear to me why Drools creates Proxies for such classes as java.util.Collections, or does MVEL do it? - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] unable to resolve token in simple mvel RHS
md5sum ../WEB-INF/lib/mvel14-1.2.21.jar 67b9f1dd16b353327a9ef4fe708a8b62 ../WEB-INF/lib/mvel14-1.2.21.jar (I'm pretty certain this time...) On Feb 19, 2008 1:41 PM, Edson Tirelli [EMAIL PROTECTED] wrote: Godmar, Can you please confirm what version of MVEL you are using? Thanks, Edson 2008/2/19, Godmar Back [EMAIL PROTECTED]: Hi, with Drools 4.0.4 and MVEL 1.4, simple RHS like this one fail for me: --- package test; dialect mvel rule Rule #1 when then System.out.println(now computing 1+1...); Integer two = new Integer(2); System.out.println(two); end --- now computing 1+1... org.mvel.CompileException: unable to resolve property: two at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:288) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109) at org.mvel.ast.ContextDeepPropertyNode.getReducedValueAccelerated(ContextDeepPropertyNode.java:26) at org.mvel.ast.PropertyASTNode.initializePropertyNode(PropertyASTNode.java:123) at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:26) at org.mvel.ExecutableAccessor.getValue(ExecutableAccessor.java:45) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:521) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:260) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109) at org.mvel.ast.LiteralDeepPropertyNode.getReducedValueAccelerated(LiteralDeepPropertyNode.java:28) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111) at org.mvel.MVEL.executeExpression(MVEL.java:235) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) at org.libx.autodetect.DroolsDriver$Host.fireAllRules(DroolsDriver.java:63) at org.libx.autodetect.DroolsDriver.main(DroolsDriver.java:136) Caused by: org.mvel.PropertyAccessException: unable to resolve property: two at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:382) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:257) ... 19 more org.mvel.CompileException: unable to resolve token: two at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:297) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109) at org.mvel.ast.LiteralDeepPropertyNode.getReducedValueAccelerated(LiteralDeepPropertyNode.java:28) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111) at org.mvel.MVEL.executeExpression(MVEL.java:235) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) at org.libx.autodetect.DroolsDriver$Host.fireAllRules(DroolsDriver.java:63) at org.libx.autodetect.DroolsDriver.main(DroolsDriver.java:136) Caused by: org.mvel.UnresolveablePropertyException: unable to resolve token: two at org.mvel.ast.PropertyASTNode.initializePropertyNode(PropertyASTNode.java:127) at org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:26) at org.mvel.ExecutableAccessor.getValue(ExecutableAccessor.java:45) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:521) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:260) ... 12 more Caused by: org.mvel.CompileException: unable to resolve property: two
[rules-users] drools fails to parse Array literals correctly when using MVEL
Consider this test:
---
package tests;
import java.lang.reflect.Method;
dialect mvel
rule Rule #1
when
then
Class clazz = Class.forName(java.lang.Class);
System.out.println(clazz = + clazz);
Method m = clazz.getDeclaredMethod(forName, new Class [] {
java.lang.String.class });
System.out.println(m = + m);
end
--
(which runs correctly when dialect java is given), fails in Drools
4.0.4/MVEL 1.4 with:
org.mvel.CompileException: could not create constructor:
java.lang.Class.init()
at
org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeObjectCreation(ReflectiveAccessorOptimizer.java:688)
at
org.mvel.ast.NewObjectNode.getReducedValueAccelerated(NewObjectNode.java:191)
at org.mvel.MVELRuntime.execute(MVELRuntime.java:88)
at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
at org.mvel.CompiledExpression.getValue(CompiledExpression.java:106)
at
org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:521)
at
org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:260)
at
org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:109)
at
org.mvel.ast.VariableDeepPropertyNode.getReducedValueAccelerated(VariableDeepPropertyNode.java:29)
at
org.mvel.ast.PropertyASTNode.initializePropertyNode(PropertyASTNode.java:77)
at
org.mvel.ast.PropertyASTNode.getReducedValueAccelerated(PropertyASTNode.java:26)
at org.mvel.ExecutableAccessor.getValue(ExecutableAccessor.java:45)
at
org.mvel.ast.TypedVarNode.getReducedValueAccelerated(TypedVarNode.java:43)
at org.mvel.MVELRuntime.execute(MVELRuntime.java:88)
at org.mvel.CompiledExpression.getValue(CompiledExpression.java:111)
at org.mvel.MVEL.executeExpression(MVEL.java:235)
at
org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47)
at
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550)
at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514)
at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471)
at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433)
at
org.libx.autodetect.DroolsDriver$Host.fireAllRules(DroolsDriver.java:63)
at org.libx.autodetect.DroolsDriver.main(DroolsDriver.java:136)
It appears to be looking for a constructor for new java.lang.Class()
rather than constructing an array.)
Similarly, o.method(new String [] { ... }) fails because it looks
for a method taking a String, rather than String[].
- Godmar
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] IllegalAccessError in shadow classes
As a general comment, the examples for which I find Drools failing are not the actual examples for which my application is failing. It's just the smallest test case I was able to eliminate. I'm now a bit concerned about your comment that Maps and Collections aren't well-defined as Facts. I am planning to make extensive use of them (that's also why I'd prefer to use the MVEL dialect, because in 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 that would have been returned by Collections.singletonMap), and with collections of maps (such as those obtained via a from... clause). I need to insert immutable maps as facts; I understand that the items returned by from aren't inserted as facts. - Godmar On Feb 19, 2008 3:11 PM, Edson Tirelli [EMAIL PROTECTED] wrote: Drools tries to create the ShadowProxy. The reason is that it does not know about the implementation... it just knows it is a Map and as so, it must be shadowed. Problem is that SingletonMap is either final or does not have a default constructor. My recommendation, besides opening a JIRA for this, is avoid inserting collections/maps directly as facts. The semantic for such facts is not clearly defined and it may cause undesired behavior. []s Edson 2008/2/19, Godmar Back [EMAIL PROTECTED]: 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 org.drools.shadow.java.util.Collections$SingletonMapShadowProxy cannot access its superclass java.util.Collections$SingletonMap at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at org.drools.rule.MapBackedClassLoader.fastFindClass(MapBackedClassLoader.java:60) at org.drools.rule.MapBackedClassLoader.loadClass(MapBackedClassLoader.java:79) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.drools.reteoo.Rete$ClassObjectTypeConf.loadOrGenerateProxy(Rete.java:547) at org.drools.reteoo.Rete$ClassObjectTypeConf.defineShadowProxyData(Rete.java:494) at org.drools.reteoo.Rete$ClassObjectTypeConf.init(Rete.java:461) at org.drools.reteoo.Rete.assertObject(Rete.java:152) at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:192) at org.drools.reteoo.ReteooWorkingMemory.doInsert(ReteooWorkingMemory.java:71) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:909) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:881) at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:67) at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:61) It's not clear to me why Drools creates Proxies for such classes as java.util.Collections, or does MVEL do it? - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of 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] drools parser loops infinitely.
That would be good. I was a bit concerned about Mark's comment implying that you deal with the mailing list first, then with JIRAs. I'm finding 4.0.4 very difficult to work with, I'm practically encountering parsing/dialect issues constantly, making it very difficult to achieve my actual goal. - Godmar On Feb 19, 2008 3:13 PM, Edson Tirelli [EMAIL PROTECTED] wrote: Ok, I guess we must hire you as our QA person. :) Please, keep reporting and opening JIRAs. I'm working on getting as much as possible fixed. []s Edson 2008/2/19, Godmar Back [EMAIL PROTECTED]: Hi, here's a simple test for which Drools 4.0.4 w/ MVEL 1.4 loops infinitely: package tests; import java.util.Map; import java.io.File; dialect mvel rule Rule #1 when p : Map (this[path] matches File.separator); then System.out.println(cgi path + p.path); end It appears to be related to the use of static String variable on the rhs of the match clause. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of 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
[rules-users] issues with parser when using MVEL dialect
Hi, I've recently upgraded to Drools 4.0.4 with mvel14-1.2.21.jar, and I'm having severe issues with its parser. For instance, this simple .drl file: -- package test; rule Rule #1 dialect mvel when then /* a single-line comment */ System.out.println(hello world); end -- results in: org.mvel.PropertyAccessException: unable to resolve property: ; at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:285) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:107) at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:185) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:107) at org.mvel.MVEL.executeExpression(MVEL.java:223) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) -- Switching to dialect java, or removing the /* single-line comment */, helps. So does replacing the comment with a // style comment. There are many more weirdnesses I'm encountering (I've filed a number of bugs already), but I'm wondering if something else isn't amiss here. I also tried mvel16-1.2.22.jar, same effect. On the other hand, running just the RHS in mvelsh works just fine. In this context, I'd like to voice the wish that Drools include a command-line driver that can load and execute .drl files for testing. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Re: issues with parser when using MVEL dialect
On closer examination, it was my bad. I discovered a mvel.jar in a directory I had in my java.exts.dir that came bundled with ZK. This mvel.jar has version 1.2beta16, and it's responsible for these failures, which don't occur with 1.2.21 or 1.2.22. Since I'm not the first to be tripped off by this (*), let me suggest this: when you load MVEL, please read org.mvel.MVEL.VERSION and org.mvel.MVEL.VERSION_SUB and bail if they're not compatible. - Godmar (*) http://lists.jboss.org/pipermail/rules-users/2008-February/004707.html On Feb 13, 2008 10:28 AM, Godmar Back [EMAIL PROTECTED] wrote: Hi, I've recently upgraded to Drools 4.0.4 with mvel14-1.2.21.jar, and I'm having severe issues with its parser. For instance, this simple .drl file: -- package test; rule Rule #1 dialect mvel when then /* a single-line comment */ System.out.println(hello world); end -- results in: org.mvel.PropertyAccessException: unable to resolve property: ; at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.compileGetChain(ReflectiveAccessorOptimizer.java:285) at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.optimizeAccessor(ReflectiveAccessorOptimizer.java:107) at org.mvel.ASTNode.getReducedValueAccelerated(ASTNode.java:185) at org.mvel.MVELRuntime.execute(MVELRuntime.java:88) at org.mvel.CompiledExpression.getValue(CompiledExpression.java:107) at org.mvel.MVEL.executeExpression(MVEL.java:223) at org.drools.base.mvel.MVELConsequence.evaluate(MVELConsequence.java:47) at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:550) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:514) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:471) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:433) -- Switching to dialect java, or removing the /* single-line comment */, helps. So does replacing the comment with a // style comment. There are many more weirdnesses I'm encountering (I've filed a number of bugs already), but I'm wondering if something else isn't amiss here. I also tried mvel16-1.2.22.jar, same effect. On the other hand, running just the RHS in mvelsh works just fine. In this context, I'd like to voice the wish that Drools include a command-line driver that can load and execute .drl files for testing. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] regular expresions
Regarding Brian's mail on capturing matches in regular expressions: this is already a feature request, see: http://jira.jboss.com/jira/browse/JBRULES-1226 - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Basic questions about rule deployment
Replacing a space with %20 has nothing to do with base 64 encoding. It's called percent-encoding (in RFC 3986) and it's required for valid URI. You may be confusing terminology here, but your point of testing with space-containing filenames is well taken. - Godmar On 10/11/07, Hehl, Thomas [EMAIL PROTECTED] wrote: Just a note about URLs. URLs will automatically do base 64 encoding, which primarily means that all spaces are replaced with %20%. If you are using a URL to represent a file, make sure you test it with a file that has spaces somewhere in the path. I just learned this the hard way. You may need to convert your URL to a URI. Good luck! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fermion Sent: Thursday, October 11, 2007 5:29 AM To: rules-users@lists.jboss.org Subject: Re: [rules-users] Basic questions about rule deployment Thank you very much! I followed your advice and created URLs for my .drl and .dsl files. Then I created a new URLClassLoader instance with these two URLs. Finally I assigned this class loader to my packager builder using: myPackageBuilder.getPackageBuilderConfiguration().setClassLoader(myURLClassL oader); Absolute path names seem to be Ok, as long as one uses file: as a prefix to the URL string. I plan to use a config file to specify the locations of my rule files (dsl and drl). The location of the config file itself will then be defined by a command line argument. Thanks again! -- View this message in context: http://www.nabble.com/Basic-questions-about-rule-deployment-tf4601653.html#a 13152365 Sent from the drools - user mailing list archive at Nabble.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 ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] does WorkingMemory.iterator support remove()?
Does the iterator returned by WorkingMemory.iterator support remove()? I checked the javadoc and the Drools manual, but may have missed it. Please answer and augment documentation. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] MVEL question: how to check containment in map's key/value set
Does MVEL provide a syntax to check for membership in a map's key or value sets, e.g., something like: map.keys contains X map containsKey X? - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] suggestion for drl grammar: single-element constraints
If a fact contains a single field, it would be nice to be able to express a constraint on the value of that field without having to know its name, e.g.: Cheese (stilton) which would be equivalent to Cheese (type == stilton) if Cheese contained only one field, and which would be a compile-time error otherwise. A similar convenience syntax is used, for instance, for Java 5 annotations. Instead of having to say @Retention(value = RetentionPolicy.RUNTIME) it can be abbreviated @Retention(RetentionPolicy.RUNTIME) since this annotation only has a single field. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] how to specify classpath dependencies in .drl files.
I don't know how to switch the compiler, but lLooking at the source, I
see that janino uses ClassLoaderIClassLoader,
http://fisheye.codehaus.org/browse/~raw,r=1.6/janino/janino/src/org/codehaus/janino/ClassLoaderIClassLoader.java
which in fact uses a reflection-based loader.
I believe I had already pointed out the problem with using reflection
to resolve external references: it can lead to unexpected first active
uses (in other words, using a class as a reference in compilation
could trigger the class's static {} initializer.) which may or may not
be tolerable (if the class is already loaded or has no static
initializer, it's not a problem - otherwise, it's a nightmare.)
In any event, this is all besides the point (at least the point I was
trying to make). I argue that a sound design should separate runtime
and compilation classpath (or at least provide the option of doing
so), but I acknowledge that the current approach is pragmatic and
probably works for a large number of cases.
To return to the original point of discussion, I'm wondering how to
make it easy for different .drl files to refer to each other. You had
brought up the Rule Agent, though it wasn't clear to me whether you
meant that the rule agent implementation as it currently exists
already has a way of specifying such dependencies, and if so, how - or
whether you are consider this a future addition.
From my (admittedly brief) examination of the the rule agent, it
appears to be a tool that monitors filesystem or network-based sources
of rules in pre-compiled packages, then loads them. What I am seeking
is a simple way for one rulebase to refer to a set of classes and
rules on which it depends, similar to how, for instance, an XML file
can refer to an external DTD or Schema.
- Godmar
On 10/2/07, Mark Proctor [EMAIL PROTECTED] wrote:
try using janino instead of eclipse jdt
Godmar Back wrote:
PS: it turns out that Drool's class loader in
org/drools/rule/PackageCompilationData.java falls back to
getResource
also (that's why I had to delete .class file in my first attempt at
RLoader.) Installing a class loader that fails getResource() for
.class files makes it even simpler to see that Drools's compilation
machinery relies on it. So, to convince yourselves, use this loader:
// RLoader.java, v2
import java.io.File;
import java.net.URL;
public class RLoader extends ClassLoader {
public RLoader() { }
public RLoader(ClassLoader parent) { super(parent); }
public Class loadClass(String name) throws ClassNotFoundException {
return getParent().loadClass(name);
}
public URL getResource(String name) {
if (name.endsWith(.class)) {
System.out.println(Classloader asked for .class file as
resource URL: + name);
new Throwable().printStackTrace();
return null;
}
return getParent().getResource(name);
}
}
and you can observe the same failure - maybe this convinces you.
- Godmar
On 9/27/07, Godmar Back [EMAIL PROTECTED] wrote:
On 9/27/07, Mark Proctor [EMAIL PROTECTED] wrote:
Godmar Back wrote:
I agree that it may not belong into the .drl file, though loading
bytecode through the classloader via getResourceAsStream() also seems
a rather ad-hoc solution.
I've already told you, that you are mistaken here. You do not need to keep
bytecode hanging around, and available via getResourceAsStream() for any
compilation to work. I can generate a class at runtime, in memory, add it
to a classloader and have the engine compile against it without
getResourceAsStream() being able to search for and return the .class'
bytecode.
Ok - here's an experiment you can perform.
Write a class loader RLoader.java as follows:
// RLoader.java
import java.io.File;
import java.io.InputStream;
public class RLoader extends ClassLoader {
public RLoader() { }
public RLoader(ClassLoader parent) { super(parent); }
public Class loadClass(String name) throws ClassNotFoundException {
return getParent().loadClass(name);
}
public InputStream getResourceAsStream(String name) {
if (name.endsWith(.class)) {
System.out.println(Classloader asked for .class file as
resource: + name);
new Throwable().printStackTrace();
// delete the .class file to ensure that no other part of
drools attempts to read it.
new File(name).delete();
return null;
}
return getParent().getResourceAsStream(name);
}
}
Now use this class as your system class loader. Specify:
-Djava.system.class.loader=RLoader
When you then run your application, you will see output such as:
Classloader asked for .class file as resource:
org/enhancementpatterns/castor/CastorEnhancements/AddVisitor.class
java.lang.Throwable
at RLoader.getResourceAsStream(RLoader.java:13)
at
org.drools.rule.PackageCompilationData$PackageClassLoader.getResourceAsStream(PackageCompilationData.java:386)
at
org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(EclipseJavaCompiler.java:282
Re: [rules-users] how to specify classpath dependencies in .drl files.
On 9/27/07, Mark Proctor [EMAIL PROTECTED] wrote:
Godmar Back wrote:
I agree that it may not belong into the .drl file, though loading
bytecode through the classloader via getResourceAsStream() also seems
a rather ad-hoc solution.
I've already told you, that you are mistaken here. You do not need to keep
bytecode hanging around, and available via getResourceAsStream() for any
compilation to work. I can generate a class at runtime, in memory, add it
to a classloader and have the engine compile against it without
getResourceAsStream() being able to search for and return the .class'
bytecode.
Ok - here's an experiment you can perform.
Write a class loader RLoader.java as follows:
// RLoader.java
import java.io.File;
import java.io.InputStream;
public class RLoader extends ClassLoader {
public RLoader() { }
public RLoader(ClassLoader parent) { super(parent); }
public Class loadClass(String name) throws ClassNotFoundException {
return getParent().loadClass(name);
}
public InputStream getResourceAsStream(String name) {
if (name.endsWith(.class)) {
System.out.println(Classloader asked for .class file as
resource: + name);
new Throwable().printStackTrace();
// delete the .class file to ensure that no other part of
drools attempts to read it.
new File(name).delete();
return null;
}
return getParent().getResourceAsStream(name);
}
}
Now use this class as your system class loader. Specify:
-Djava.system.class.loader=RLoader
When you then run your application, you will see output such as:
Classloader asked for .class file as resource:
org/enhancementpatterns/castor/CastorEnhancements/AddVisitor.class
java.lang.Throwable
at RLoader.getResourceAsStream(RLoader.java:13)
at
org.drools.rule.PackageCompilationData$PackageClassLoader.getResourceAsStream(PackageCompilationData.java:386)
at
org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(EclipseJavaCompiler.java:282)
at
org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(EclipseJavaCompiler.java:313)
at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.isPackage(LookupEnvironment.java:1157)
at
org.eclipse.jdt.internal.compiler.lookup.PackageBinding.findPackage(PackageBinding.java:75)
at
org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:190)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:438)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:492)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:356)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:425)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:589)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
at
org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:353)
at
org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:51)
at
org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:332)
at org.drools.compiler.DialectRegistry.compileAll(DialectRegistry.java:60)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:288)
at
org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:158)
Leading to failures such as:
Exception in thread main org.drools.rule.InvalidRulePackage: Rule
Compilation error : [Rule name=Add Visitors, agendaGroup=MAIN,
salience=0, no-loop=false]
org/enhancementpatterns/castor/test/Rule_Add_Visitors_0.java
(3:127) : Only a type can be imported.
org.enhancementpatterns.castor.CastorEnhancements.AddVisitor resolves
to a package
- Godmar
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] how to specify classpath dependencies in .drl files.
PS: it turns out that Drool's class loader in
org/drools/rule/PackageCompilationData.java falls back to getResource
also (that's why I had to delete .class file in my first attempt at
RLoader.) Installing a class loader that fails getResource() for
.class files makes it even simpler to see that Drools's compilation
machinery relies on it. So, to convince yourselves, use this loader:
// RLoader.java, v2
import java.io.File;
import java.net.URL;
public class RLoader extends ClassLoader {
public RLoader() { }
public RLoader(ClassLoader parent) { super(parent); }
public Class loadClass(String name) throws ClassNotFoundException {
return getParent().loadClass(name);
}
public URL getResource(String name) {
if (name.endsWith(.class)) {
System.out.println(Classloader asked for .class file as
resource URL: + name);
new Throwable().printStackTrace();
return null;
}
return getParent().getResource(name);
}
}
and you can observe the same failure - maybe this convinces you.
- Godmar
On 9/27/07, Godmar Back [EMAIL PROTECTED] wrote:
On 9/27/07, Mark Proctor [EMAIL PROTECTED] wrote:
Godmar Back wrote:
I agree that it may not belong into the .drl file, though loading
bytecode through the classloader via getResourceAsStream() also seems
a rather ad-hoc solution.
I've already told you, that you are mistaken here. You do not need to keep
bytecode hanging around, and available via getResourceAsStream() for any
compilation to work. I can generate a class at runtime, in memory, add it
to a classloader and have the engine compile against it without
getResourceAsStream() being able to search for and return the .class'
bytecode.
Ok - here's an experiment you can perform.
Write a class loader RLoader.java as follows:
// RLoader.java
import java.io.File;
import java.io.InputStream;
public class RLoader extends ClassLoader {
public RLoader() { }
public RLoader(ClassLoader parent) { super(parent); }
public Class loadClass(String name) throws ClassNotFoundException {
return getParent().loadClass(name);
}
public InputStream getResourceAsStream(String name) {
if (name.endsWith(.class)) {
System.out.println(Classloader asked for .class file as
resource: + name);
new Throwable().printStackTrace();
// delete the .class file to ensure that no other part of
drools attempts to read it.
new File(name).delete();
return null;
}
return getParent().getResourceAsStream(name);
}
}
Now use this class as your system class loader. Specify:
-Djava.system.class.loader=RLoader
When you then run your application, you will see output such as:
Classloader asked for .class file as resource:
org/enhancementpatterns/castor/CastorEnhancements/AddVisitor.class
java.lang.Throwable
at RLoader.getResourceAsStream(RLoader.java:13)
at
org.drools.rule.PackageCompilationData$PackageClassLoader.getResourceAsStream(PackageCompilationData.java:386)
at
org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(EclipseJavaCompiler.java:282)
at
org.drools.commons.jci.compilers.EclipseJavaCompiler$2.isPackage(EclipseJavaCompiler.java:313)
at
org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.isPackage(LookupEnvironment.java:1157)
at
org.eclipse.jdt.internal.compiler.lookup.PackageBinding.findPackage(PackageBinding.java:75)
at
org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:190)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findImport(CompilationUnitScope.java:438)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.findSingleImport(CompilationUnitScope.java:492)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:356)
at
org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:425)
at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:589)
at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:411)
at
org.drools.commons.jci.compilers.EclipseJavaCompiler.compile(EclipseJavaCompiler.java:353)
at
org.drools.commons.jci.compilers.AbstractJavaCompiler.compile(AbstractJavaCompiler.java:51)
at
org.drools.rule.builder.dialect.java.JavaDialect.compileAll(JavaDialect.java:332)
at org.drools.compiler.DialectRegistry.compileAll(DialectRegistry.java:60)
at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:288)
at
org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:158)
Leading to failures such as:
Exception in thread main org.drools.rule.InvalidRulePackage: Rule
Compilation error : [Rule name=Add Visitors, agendaGroup=MAIN,
salience
Re: [rules-users] how to specify classpath dependencies in .drl files.
On 9/26/07, Edson Tirelli [EMAIL PROTECTED] wrote: Drools does not have any special treatment/feature for classloaders. Default java classloader hirarchy is used. So, set your URLClassLoader as the context classloader before building the package and it shall work. I find it unlikely that this works. The compiler probably won't load classes from the context classloader (after all, the classloader doesn't have an interface to obtain the bytecode associated with a name - all it provides is a method to retrieve a java.lang.Class object, which the compiler doesn't need. The compiler needs to examine the bytecode of referred classes.) Even if it did work, it would be insufficient because I do not know the URL until I've seen the drl file. Otherwise, I would have to keep that dependency information somewhere else - I'd like to keep it in the .drl file and let drool do the work. Let me propose the following enhancement. Add an optional from clause to the import statement. For instance, allow a user to say: import org.somefeature.somepackage from http://somefeature.org/ourpackages.jar; This would instruct the compiler to include this .jar in its compile class path. In addition, it would compile a list of jar URLs upon which the rules depend when being executed. A method on package builder could then be added that would retrieve that list of URLs such that a classloader could be created to load those classes. Either URL [] PackageBuilder.getReferencedURLs() or possibly better ClassLoader PackageBuilder.createLoader() where a suitably configured subclass of URLClassLoader is returned. - Godmar 2007/9/25, Godmar Back [EMAIL PROTECTED]: My question is how to manage a rule base that is composed from sets of rules drawn from different sources. Our goal is to supply sets of rules as .jar files - each .jar file containing a related set of rules. For instance, consider an expert system where different experts could export their expertise in such a jar file. Such a .jar file would contain one or more .drl files and a set of supporting .java classes. We'd like to be able to refer to these .jar files using a URLClassLoader and/or JarURLConnection so they can be referred to without a user having to download them prior to starting their application. Users should be able to combine those provided rules (that is, the rules of those experts whose knowledge they wish to exploit) with their own rules in their own .drl files. My question is whether drools supports such a setup easily. Specifically, is there a way for a user to import external .jar files in their .drl files? A statement such as use jar:http://expertbase.com/expert1/knowledge5.jar which would instruct the rule compiler to load the classes from this jar to its compile class path, and which would instruct the class loader used to load the user's classes to delegate to the loader used to load the jar file's classes? [Note that a given expert's knowledge should only be loaded by one classloader.] I browsed through the API and discovered that the package builder configuration allows the specification of a class loader. Does this mean the rule compiler will attempt to load related classes through this loader as well? If so, it would need to use reflection to examine those classes (which I'd find unlikely). If not, is there a way to control the rule compiler's compiler classpath? In our current prototype, we need to load everything through the application classpath to avoid compile errors. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli Software Engineer - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of 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
[rules-users] escaping backslash in matches clauses (documentation bug?)
The documentation states that '\' occurring in matches clauses do not need escaping. However, unescaped '\' cause this error message when compiling the .drl file: Exception in thread main org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=Apply XML Descriptor, agendaGroup=MAIN, salience=0, no-loop=false] at org.drools.rule.Package.checkValidity(Package.java:419) at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:292) Escaping the '\' as is customary in Java makes the code work. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Re: escaping backslash in matches clauses (documentation bug?)
PS. I was a bit too quick with my email; that is not to say that I don't suspect there to be a problem. It appears to depend on whether the left-hand side of the matches clause is a field or a Java expression. For instance: f : Fact( w matches \. ) does not require escaping in accordance with the documentation, but if I match on a different expression: f : Fact(w.somebeanproperty matches \\.) escaping the \ becomes required. - Godmar On 9/25/07, Godmar Back [EMAIL PROTECTED] wrote: The documentation states that '\' occurring in matches clauses do not need escaping. However, unescaped '\' cause this error message when compiling the .drl file: Exception in thread main org.drools.rule.InvalidRulePackage: Unable to determine the used declarations : [Rule name=Apply XML Descriptor, agendaGroup=MAIN, salience=0, no-loop=false] at org.drools.rule.Package.checkValidity(Package.java:419) at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:292) Escaping the '\' as is customary in Java makes the code work. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] dialect: Java or MVEL
BTW, when using Java, is there a way to save the .java files created by the compiler? I would like to understand the specific environment/scope in which consequences are compiled. Right now, if something goes wrong, the .java are deleted right away. I looked at PackageBuilderOptions, but didn't see anything there. - Godmar On 9/24/07, Mark Proctor [EMAIL PROTECTED] wrote: Java is more mature in tooling and implementation and is still currently the default implementation and the recommended one if you are not sure. MVEL will eventually become the default dialect when it matures, its advantage is in the simpler language it provides, which helps make rules easier to read and write. It can also operate in reflection mode, which can really help for large rule based systems that have perm gen issues. Mark ekke wrote: can someone tell me, when to use java or mvel as dialect ? I've experienced that in some cases inside the drl editor using java gives me more context-help then using mvel but: what can I do with java and not with mvel and what advantages has mvel compared with java which dialect is more performant ? thx for infos from insiders ekke ___ 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
[rules-users] capturing matches from regular expressions?
Hi, is there a syntax to capture the match(es) from a regular expression inside a matches condition in a when statement, similar to Matcher.group(int) in Java's regexps or $1, $2, $3 in Perl work? Thanks. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] capturing matches from regular expressions?
On 9/22/07, Edson Tirelli [EMAIL PROTECTED] wrote: Sorry, nope. Is there a use case for that? For instance, I'd like to write a rule where I need to be alerted of all facts where a specific field is of the form (.*)Suffix. The action I'm then taking requires the (.*) as a parameter. The value of Suffix does not matter to the action and should be restricted to the .drl file (as it matters there only.) If I cannot capture the match, I will have to pay both a cost in runtime and in expressiveness. In runtime because the regular expression match is repeated in the action. In expressiveness, because my code is now less localized since there will be 2 places that deal with Suffix. If I repeated Suffix in the match and action as a string literal, changing it would require changing it in two places: when n : Name (value matches (.*)Suffix) then TakeAction(n, Suffix) I do not know if I could use a variable, as in final String suffix = Suffix; when n : Name (value matches ((.*) + suffix)) then TakeAction(n, suffix) but even then, the code is less expressive and the match would need to repeated; in any event, I'd like to be able to write something along the lines of: when n : Name (value matches (.*)Suffix) some way to bind presuffix to $1 then TakeAction(presuffix) where presuffix captures $1 in the match. This way, I'd have to change Suffix only once. - Godmar ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
