[jira] [Commented] (JENA-1204) Independently Configurable BulitinRegistry for Jena Rules Engine

["Paul Houle (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-1204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15362626#comment-15362626 ] 

Paul Houle commented on JENA-1204:
----------------------------------

Here is some analysis.  The only place where the BuiltinRegistry is created is in the Rule class,  not the reasoner class.  In the Rule class they are embedded in the static methods that parse rules,  although in the context of a inner Parser class,  passing the registry to the constructor of Functor.  Thus to have UDF's visible to the parser and usable in written-down code,  we just have to make the user-visible parser configurable.  (Float it out as an object?  Would thread-local be too radical?)

Already if somebody is creating Functor objects programatically,  they have a choice of wiring up an alternative registry and,  actually, all that the constructor does with the registry is get the implementation Builtin,  so the ideal mechanism would be to have the constructor accept the implementation directly.


> Independently Configurable BulitinRegistry for Jena Rules Engine
> ----------------------------------------------------------------
>
>                 Key: JENA-1204
>                 URL: https://issues.apache.org/jira/browse/JENA-1204
>             Project: Apache Jena
>          Issue Type: Bug
>          Components: Jena
>    Affects Versions: Jena 3.1.1
>         Environment: any
>            Reporter: Paul Houle
>              Labels: rules
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> An appealing case for the Jena Rules Engine is to use rules to trigger a set of actions in the rule heads that create side effects in the Java Universe:  consider (1) constructing and populating Java data structures in the rule head,  and (2) use of the rules engine in a "reactive" scenario where changes in the outside world are inserted into the graph as facts,  triggering actions on a distributed system in the heads.
> In cases like this,  the creation of a new set of built-ins could occur somewhat frequently so efficiency matters here so I don't like the idea of this registered in some central registry so that we can pass in the built-in parameter with the resource to the factory,  so the advised method for configuration is to add a setter on the GenericRuleReasoner,  The only concern I have is "order-of-operations" involving initialization,  etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)