[rules-users] IllegalAccessError in shadow classes

[Mark Proctor]

Edson Tirelli 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.
The engine is already mostly model independant, via our use of 
ObjectType and Extractor interfaces. Its now a matter of making that 
design clean and pluggable. I'm hoping that once we remove shadow 
proxies when I merge my branch, for 5.0, having pluggable extractors 
will be even easier.
>
>    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 <godmar at gmail.com <mailto:godmar at gmail.com>>:
>
>     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 <tirelli at post.com
>     <mailto:tirelli at post.com>> 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 at lists.jboss.org <mailto: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 <http://www.jboss.com>
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080220/14b09063/attachment.html