Thanks, I've committed the changes from the patch.

If you can confirm that they look OK to you and then close the jira.

Dave

On 18/04/14 14:15, Sébastien Boulet wrote:
Ok,

i have just proposed a patch with these modifications.

https://issues.apache.org/jira/browse/JENA-679

Seb


: : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
Sébastien Boulet
Lead développeur

intactile DESIGN
: : Création d’interfaces subtiles : :
+33 (0)4 67 52 88 61
+33 (0)6 89 34 24 12
20 rue du Carré du Roi
34 000 Montpellier, France
www.intactile.com

Le 15 avr. 2014 à 19:07, Dave Reynolds <[email protected]> a écrit :


On 15/04/14 14:55, Sébastien Boulet wrote:
Hi all,

i would like to use an alternative implementation of the FRuleEngineI. My 
problem is that the FRuleEngineI is instantiated directly from two locations :
in com.hp.hpl.jena.reasoner.rulesys.FBRuleInfGraph
     @Override
     protected void instantiateRuleEngine(List<Rule> rules) {
         if (rules != null) {
             if (useRETE) {
                 engine = new RETEEngine(this, rules);
             } else {
                 engine = new FRuleEngine(this, rules);
             }
         } else {
             if (useRETE) {
                 engine = new RETEEngine(this);
             } else {
                 engine = new FRuleEngine(this);
             }
         }
     }
and in com.hp.hpl.jena.reasoner.rulesys.RETERuleInfGraph

     @Override
     protected void instantiateRuleEngine(List<Rule> rules) {
         if (rules != null) {
             engine = new RETEEngine(this, rules);
         } else {
             engine = new RETEEngine(this);
         }
     }

For now, if i want to use another FRuleEngineI, i have to sub class theses 
classes for instantiating my own FRuleEngineI implementation. And since theses 
classes (FBRuleInfGraph, RETERuleInfGraph) are instantiated directly by others 
ones (GenericRuleReasoner, FBRuleReasoner, OWLFBRuleReasoner…), i will have to 
sub class a lot of existing classes.

So my question is, is there an easiest way to do this ?

No. It's not be a usecase that's come up before. People have sometimes done 
custom versions of FBRuleInfGraph or created new sorts of InfGraph but I'm not 
aware of anyone previously replacing the forward engine across all existing 
InfGraph types.

If not, i was thinking of introducing a singleton FRuleEngineIFactory (I kept 
the useRETE  flag for backward compatibility.) :

[Yeah the non-RETE engine and the useRETE flag ought to be removed sometime but 
for now it's in there.]

public class FRuleEngineIFactory {
     private static FRuleEngineIFactory instance;

[needs to be initialized :)]

     public static void setInstance(FRuleEngineIFactory instance) { 
FRuleEngineIFactory.instance = instance; }
     public FRuleEngineIFactory getInstance() { return instance; }

     public FRuleEngineI createFRuleEngineI(ForwardRuleInfGraphI parent, 
List<Rule> rules, boolean useRETE) {
         FRuleEngineI engine;
         if (rules != null) {
             if (useRETE) {
                 engine = new RETEEngine(parent, rules);
             } else {
                 engine = new FRuleEngine(parent, rules);
             }
         } else {
             if (useRETE) {
                 engine = new RETEEngine(parent);
             } else {
                 engine = new FRuleEngine(parent);
             }
         }
         return engine;
     }
}

This factory might be used by

com.hp.hpl.jena.reasoner.rulesys.FBRuleInfGraph
     @Override
     protected void instantiateRuleEngine(List<Rule> rules) {
         engine = FRuleEngineIFactory.getInstance().createFRuleEngineI(this, 
rules, useRETE);
     }

and by com.hp.hpl.jena.reasoner.rulesys.RETERuleInfGraph
     @Override
     protected void instantiateRuleEngine(List<Rule> rules) {
         engine = FRuleEngineIFactory.getInstance().createFRuleEngineI(this, 
rules, true);
     }

And i could replace the factory instance by my own instance :

         FRuleEngineIFactory.setInstance(new CustomFRuleEngineIFactory());


What do you think of that ?

Sure. That would enable the sort of plug point you are after without causing 
knock on problems.

Dave



Reply via email to