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