[rules-users] IllegalAccessError in shadow classes
Edson Tirelli
tirelli at post.com
Wed Feb 20 12:30:00 EST 2008
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? More than that, the shadow must be a subclass of it.
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?
[]s
Edson
2008/2/20, Godmar Back <godmar at gmail.com>:
>
> 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 <tirelli at post.com> 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 <godmar at gmail.com>:
> >
> > > On Feb 20, 2008 9:23 AM, Edson Tirelli <tirelli at post.com> 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 <godmar at gmail.com>:
> > > > > 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 at 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 at 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 at 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 at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > > > >
> > > > > >
> > > > > _______________________________________________
> > > > > rules-users mailing list
> > > > > rules-users at 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 at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> _______________________________________________
> rules-users mailing list
> rules-users at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080220/300fd58e/attachment.html
More information about the rules-users
mailing list