You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by Sébastien Boulet <bo...@intactile.com> on 2014/04/15 15:55:18 UTC
Use an alternative implementation of a FRuleEngineI
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 ?
If not, i was thinking of introducing a singleton FRuleEngineIFactory (I kept the useRETE flag for backward compatibility.) :
public class FRuleEngineIFactory {
private static FRuleEngineIFactory instance;
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 ?
Regards,
Seb
: : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
Sébastien Boulet
Lead développeur
intactile DESIGN
: : Création d’interfaces subtiles : :
+33 (0)4 67 52 88 61
+33 (0)6 00 11 22 33
20 rue du Carré du Roi
34 000 Montpellier, France
www.intactile.com
Re: Use an alternative implementation of a FRuleEngineI
Posted by Andy Seaborne <an...@apache.org>.
On 22/04/14 15:17, Sébastien Boulet wrote:
> Thanks for your answer.
>
> For now, i will copy the testing directory in my project.
Probably the best option, certainly the quickest.
More backgound:
There are a number of test suites that run from testing/ for different
modules. e.g. the SPARQL WG test suite, RDf WG test suite, .... Those
are assumed to be located in files (with URLs at least). It would be
possible and non-trivial to convert to work out of "resources", maybe
with a adapter for the Stream Manager which sits on the model.read path.
But for now, it means the <type>tests</type> artifacts are really there
to pass the testing frameworks between modules, and not enable the tests
to be run outside a checked-out Jena codebase.
Andy
>
> 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 22 avr. 2014 à 11:26, Dave Reynolds <da...@gmail.com> a écrit :
>
>>
>> [This may be a discussion to move to dev.]
>>
>> The project test set up pre-dates use of Maven and indeed could probably follow conventions better. However, changing that would be a lot of work given that there are around 3000 (about 16Mb in total) test resources used across the various systems. Such a change is unlikely to happen in the near future, though perhaps something to consider in any future move towards e.g. jena 3.
>>
>> For your current development you will need to find a work-around I'm afraid.
>>
>> Presumably you could copy or symlink the testing directory into your project to at least enable you to proceed, even if that's not a satisfying approach.
>>
>> Many of the tests probably use the FileManager to load the test data/test results and you can register alternative Locators with the FileManager as part of your test setup. Whether that is any cleaner than the brute force work-around, and whether it would cover enough of the tests to meet your needs I don't know.
>>
>> Dave
>>
>> On 22/04/14 09:54, Sébastien Boulet wrote:
>>> Hi all,
>>>
>>> we are working on a new FRuleEngineI implementation I would like to run all the jena-core tests on our implementation.
>>> To do this, i have added a dependency in the jena-core test module :
>>>
>>> <dependency>
>>> <groupId>org.apache.jena</groupId>
>>> <artifactId>jena-core</artifactId>
>>> <version>2.11.2-SNAPSHOT</version>
>>> <type>test-jar</type>
>>> <scope>test</scope>
>>> </dependency>
>>>
>>> and i have configured the following test suite in my project. This test suite register our engine implementation and add the
>>> com.hp.hpl.jena.reasoner.test.TestPackage test suite.
>>>
>>> import junit.framework.TestSuite;
>>> import com.hp.hpl.jena.reasoner.rulesys.impl.FRuleEngineIFactory;
>>>
>>> public class EngineTestPackage extends TestSuite {
>>> public static TestSuite suite() {
>>> // use my engine implementation JENA-679
>>> FRuleEngineIFactory.setInstance(new MyEngineFactory());
>>> return new EngineTestPackage();
>>> }
>>>
>>> private EngineTestPackage() {
>>> super("myEngine");
>>> addTest("reasoners", com.hp.hpl.jena.reasoner.test.TestPackage.suite());
>>> }
>>>
>>> private void addTest(String name, TestSuite tc) {
>>> tc.setName(name);
>>> addTest(tc);
>>> }
>>> }
>>>
>>> Then run the tests using maven
>>> $ mvn test
>>>
>>> The principle works but a lot of tests are failing because of the following exception :
>>> com.hp.hpl.jena.shared.NotFoundException: Not found: file:testing/reasoners/owl/tbox.owl
>>> at com.hp.hpl.jena.util.FileManager.readModelWorker(FileManager.java:423)
>>> at com.hp.hpl.jena.util.FileManager.loadModelWorker(FileManager.java:333)
>>> at com.hp.hpl.jena.util.FileManager.loadModel(FileManager.java:285)
>>> at com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.testResults(OWLConsistencyTest.java:119)
>>> at com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.runTest(OWLConsistencyTest.java:137)
>>>
>>> The problem is that the tests resources are in a testing folder in the jena-core module. So these resources are not included by maven in the test jar.
>>>
>>> Is it possible to follow the maven convention and put all the jena-core test resources in the src/test/resources folder ?
>>>
>>> Regards
>>>
>>> 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 18 avr. 2014 à 16:57, Sébastien Boulet <bo...@intactile.com> a écrit :
>>>
>>>> It is ok.
>>>>
>>>> Thanks Dave
>>>>
>>>> : : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
>>>> 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 18 avr. 2014 à 16:17, Dave Reynolds <da...@gmail.com> a écrit :
>>>>
>>>>>
>>>>> 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 <da...@gmail.com> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
Re: Use an alternative implementation of a FRuleEngineI
Posted by Sébastien Boulet <bo...@intactile.com>.
Thanks for your answer.
For now, i will copy the testing directory in my project.
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 22 avr. 2014 à 11:26, Dave Reynolds <da...@gmail.com> a écrit :
>
> [This may be a discussion to move to dev.]
>
> The project test set up pre-dates use of Maven and indeed could probably follow conventions better. However, changing that would be a lot of work given that there are around 3000 (about 16Mb in total) test resources used across the various systems. Such a change is unlikely to happen in the near future, though perhaps something to consider in any future move towards e.g. jena 3.
>
> For your current development you will need to find a work-around I'm afraid.
>
> Presumably you could copy or symlink the testing directory into your project to at least enable you to proceed, even if that's not a satisfying approach.
>
> Many of the tests probably use the FileManager to load the test data/test results and you can register alternative Locators with the FileManager as part of your test setup. Whether that is any cleaner than the brute force work-around, and whether it would cover enough of the tests to meet your needs I don't know.
>
> Dave
>
> On 22/04/14 09:54, Sébastien Boulet wrote:
>> Hi all,
>>
>> we are working on a new FRuleEngineI implementation I would like to run all the jena-core tests on our implementation.
>> To do this, i have added a dependency in the jena-core test module :
>>
>> <dependency>
>> <groupId>org.apache.jena</groupId>
>> <artifactId>jena-core</artifactId>
>> <version>2.11.2-SNAPSHOT</version>
>> <type>test-jar</type>
>> <scope>test</scope>
>> </dependency>
>>
>> and i have configured the following test suite in my project. This test suite register our engine implementation and add the
>> com.hp.hpl.jena.reasoner.test.TestPackage test suite.
>>
>> import junit.framework.TestSuite;
>> import com.hp.hpl.jena.reasoner.rulesys.impl.FRuleEngineIFactory;
>>
>> public class EngineTestPackage extends TestSuite {
>> public static TestSuite suite() {
>> // use my engine implementation JENA-679
>> FRuleEngineIFactory.setInstance(new MyEngineFactory());
>> return new EngineTestPackage();
>> }
>>
>> private EngineTestPackage() {
>> super("myEngine");
>> addTest("reasoners", com.hp.hpl.jena.reasoner.test.TestPackage.suite());
>> }
>>
>> private void addTest(String name, TestSuite tc) {
>> tc.setName(name);
>> addTest(tc);
>> }
>> }
>>
>> Then run the tests using maven
>> $ mvn test
>>
>> The principle works but a lot of tests are failing because of the following exception :
>> com.hp.hpl.jena.shared.NotFoundException: Not found: file:testing/reasoners/owl/tbox.owl
>> at com.hp.hpl.jena.util.FileManager.readModelWorker(FileManager.java:423)
>> at com.hp.hpl.jena.util.FileManager.loadModelWorker(FileManager.java:333)
>> at com.hp.hpl.jena.util.FileManager.loadModel(FileManager.java:285)
>> at com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.testResults(OWLConsistencyTest.java:119)
>> at com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.runTest(OWLConsistencyTest.java:137)
>>
>> The problem is that the tests resources are in a testing folder in the jena-core module. So these resources are not included by maven in the test jar.
>>
>> Is it possible to follow the maven convention and put all the jena-core test resources in the src/test/resources folder ?
>>
>> Regards
>>
>> 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 18 avr. 2014 à 16:57, Sébastien Boulet <bo...@intactile.com> a écrit :
>>
>>> It is ok.
>>>
>>> Thanks Dave
>>>
>>> : : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
>>> 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 18 avr. 2014 à 16:17, Dave Reynolds <da...@gmail.com> a écrit :
>>>
>>>>
>>>> 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 <da...@gmail.com> 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
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
Re: Use an alternative implementation of a FRuleEngineI
Posted by Dave Reynolds <da...@gmail.com>.
[This may be a discussion to move to dev.]
The project test set up pre-dates use of Maven and indeed could probably
follow conventions better. However, changing that would be a lot of work
given that there are around 3000 (about 16Mb in total) test resources
used across the various systems. Such a change is unlikely to happen in
the near future, though perhaps something to consider in any future move
towards e.g. jena 3.
For your current development you will need to find a work-around I'm
afraid.
Presumably you could copy or symlink the testing directory into your
project to at least enable you to proceed, even if that's not a
satisfying approach.
Many of the tests probably use the FileManager to load the test
data/test results and you can register alternative Locators with the
FileManager as part of your test setup. Whether that is any cleaner than
the brute force work-around, and whether it would cover enough of the
tests to meet your needs I don't know.
Dave
On 22/04/14 09:54, Sébastien Boulet wrote:
> Hi all,
>
> we are working on a new FRuleEngineI implementation I would like to run all the jena-core tests on our implementation.
> To do this, i have added a dependency in the jena-core test module :
>
> <dependency>
> <groupId>org.apache.jena</groupId>
> <artifactId>jena-core</artifactId>
> <version>2.11.2-SNAPSHOT</version>
> <type>test-jar</type>
> <scope>test</scope>
> </dependency>
>
> and i have configured the following test suite in my project. This test suite register our engine implementation and add the
> com.hp.hpl.jena.reasoner.test.TestPackage test suite.
>
> import junit.framework.TestSuite;
> import com.hp.hpl.jena.reasoner.rulesys.impl.FRuleEngineIFactory;
>
> public class EngineTestPackage extends TestSuite {
> public static TestSuite suite() {
> // use my engine implementation JENA-679
> FRuleEngineIFactory.setInstance(new MyEngineFactory());
> return new EngineTestPackage();
> }
>
> private EngineTestPackage() {
> super("myEngine");
> addTest("reasoners", com.hp.hpl.jena.reasoner.test.TestPackage.suite());
> }
>
> private void addTest(String name, TestSuite tc) {
> tc.setName(name);
> addTest(tc);
> }
> }
>
> Then run the tests using maven
> $ mvn test
>
> The principle works but a lot of tests are failing because of the following exception :
> com.hp.hpl.jena.shared.NotFoundException: Not found: file:testing/reasoners/owl/tbox.owl
> at com.hp.hpl.jena.util.FileManager.readModelWorker(FileManager.java:423)
> at com.hp.hpl.jena.util.FileManager.loadModelWorker(FileManager.java:333)
> at com.hp.hpl.jena.util.FileManager.loadModel(FileManager.java:285)
> at com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.testResults(OWLConsistencyTest.java:119)
> at com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.runTest(OWLConsistencyTest.java:137)
>
> The problem is that the tests resources are in a testing folder in the jena-core module. So these resources are not included by maven in the test jar.
>
> Is it possible to follow the maven convention and put all the jena-core test resources in the src/test/resources folder ?
>
> Regards
>
> 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 18 avr. 2014 à 16:57, Sébastien Boulet <bo...@intactile.com> a écrit :
>
>> It is ok.
>>
>> Thanks Dave
>>
>> : : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
>> 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 18 avr. 2014 à 16:17, Dave Reynolds <da...@gmail.com> a écrit :
>>
>>>
>>> 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 <da...@gmail.com> 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
>>>>
>>>>
>>>
>>
>
>
Re: Use an alternative implementation of a FRuleEngineI
Posted by Sébastien Boulet <bo...@intactile.com>.
Hi all,
we are working on a new FRuleEngineI implementation I would like to run all the jena-core tests on our implementation.
To do this, i have added a dependency in the jena-core test module :
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-core</artifactId>
<version>2.11.2-SNAPSHOT</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
and i have configured the following test suite in my project. This test suite register our engine implementation and add the
com.hp.hpl.jena.reasoner.test.TestPackage test suite.
import junit.framework.TestSuite;
import com.hp.hpl.jena.reasoner.rulesys.impl.FRuleEngineIFactory;
public class EngineTestPackage extends TestSuite {
public static TestSuite suite() {
// use my engine implementation JENA-679
FRuleEngineIFactory.setInstance(new MyEngineFactory());
return new EngineTestPackage();
}
private EngineTestPackage() {
super("myEngine");
addTest("reasoners", com.hp.hpl.jena.reasoner.test.TestPackage.suite());
}
private void addTest(String name, TestSuite tc) {
tc.setName(name);
addTest(tc);
}
}
Then run the tests using maven
$ mvn test
The principle works but a lot of tests are failing because of the following exception :
com.hp.hpl.jena.shared.NotFoundException: Not found: file:testing/reasoners/owl/tbox.owl
at com.hp.hpl.jena.util.FileManager.readModelWorker(FileManager.java:423)
at com.hp.hpl.jena.util.FileManager.loadModelWorker(FileManager.java:333)
at com.hp.hpl.jena.util.FileManager.loadModel(FileManager.java:285)
at com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.testResults(OWLConsistencyTest.java:119)
at com.hp.hpl.jena.reasoner.rulesys.test.OWLConsistencyTest.runTest(OWLConsistencyTest.java:137)
The problem is that the tests resources are in a testing folder in the jena-core module. So these resources are not included by maven in the test jar.
Is it possible to follow the maven convention and put all the jena-core test resources in the src/test/resources folder ?
Regards
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 18 avr. 2014 à 16:57, Sébastien Boulet <bo...@intactile.com> a écrit :
> It is ok.
>
> Thanks Dave
>
> : : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
> 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 18 avr. 2014 à 16:17, Dave Reynolds <da...@gmail.com> a écrit :
>
>>
>> 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 <da...@gmail.com> 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
>>>
>>>
>>
>
Re: Use an alternative implementation of a FRuleEngineI
Posted by Sébastien Boulet <bo...@intactile.com>.
It is ok.
Thanks Dave
: : . . . . . . . . . . . . . . . . . . . . . . . . . . : :
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 18 avr. 2014 à 16:17, Dave Reynolds <da...@gmail.com> a écrit :
>
> 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 <da...@gmail.com> 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
>>
>>
>
Re: Use an alternative implementation of a FRuleEngineI
Posted by Dave Reynolds <da...@gmail.com>.
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 <da...@gmail.com> 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
>
>
Re: Use an alternative implementation of a FRuleEngineI
Posted by Sébastien Boulet <bo...@intactile.com>.
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 <da...@gmail.com> 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
Re: Use an alternative implementation of a FRuleEngineI
Posted by Dave Reynolds <da...@gmail.com>.
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