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 <tirelli(a)post.com> 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 <godmar(a)gmail.com>:
>
>
>
> 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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users