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
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
() );
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
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
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
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
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
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
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
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
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:
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
,
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
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 });
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
.
- 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
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:
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
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
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
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
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
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
, 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
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
().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
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
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
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
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
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
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
32 matches
Mail list logo
