Re Step 2 - I just made a commit to trunk so that with the latest code you
can extend UpdateEngineMain and simply override the protected
prepareWorker() method to return your custom UpdateVisitor rather than the
default UpdateEngineWorker I.e. this avoids the need to implement the
execute() method yourself


Also in Step 3 you should be extending from UpdateEngineWorker rather than
the non-existent UpdateWorker

Hope this helps,

Rob

On 10/29/12 9:53 AM, "Rob Vesse" <[email protected]> wrote:

>Hey Dick
>
>Yes we do this in our product in a production environment to replace the
>standard update handling with our own completely custom one
>
>Your desired extension is actually even easier than ours, extending Update
>evaluation basically requires you to do three things as follows.
>
>1 - Create and register a custom UpdateEngineFactory
>
>Create a class that implements the UpdateEngineFactory interface, this has
>two methods for you to implement.  Simply return true for the accept()
>method to indicate you wish to handle all updates and then for the
>create() method return a new instance of the class you create in Step 2
>
>Your code will need to ensure that this factory gets registered by calling
>UpdateEngineRegistry.add(new CustomUpdateEngineFactory()); in order for
>your code to intercept updates.
>
>2 - Create a custom UpdateEngine
>
>Create a class that extends from UpdateEngineBase and implements the
>abstract execute() method, you can simply modify the default
>implementation found in UpdateEngineMain like so:
>
>@Override
>    public void execute()
>    {
>  graphStore.startRequest(request) ;
>  CustomUpdateEngineWorker worker = new
>CustomUpdateEngineWorker(graphStore, startBinding, context) ;
>  for ( Update up : request ) {
>    up.visit(worker) ;
>  }
>  graphStore.finishRequest(request) ;
>    }
>
>
>3 - Create your custom UpdateVisitor
>
>Create a class that extends from UpdateWorker, this is the class you are
>referencing as CustomUpdateEngineWorker from Step 2, I assume you pick a
>more appropriate name.  Then you simply override the methods that you want
>to add access control functionality to like so:
>
>@Override
>public void visit(UpdateCreate update)
>{
>  if (deny(args)) {
>    //Handle the error case
>  } else {
>    //Otherwise defer to normal logic
>    super.visit(update);
>  }
>}
>
>Hope this helps,
>
>Rob
>
>
>
>On 10/29/12 6:43 AM, "Dick Murray" <[email protected]> wrote:
>
>>Hi all
>>
>>I need to permit/deny certain SPARUL update operations e.g. deny create|
>>drop graph.
>>
>>I've looked at the UpdateEngineMain and UpdateVisitor classes and was
>>wondering if anyone has extended or encapsulated these before? Ideally
>>I'd
>>like to capture the "visit" just prior to the actual visit.
>>
>>i.e the UpdateEngineWorker has...
>>
>>    @Override
>>    public void visit(UpdateCreate update)
>>    {
>>        Node g = update.getGraph() ;
>>        if ( g == null )
>>            return ;
>>        if ( graphStore.containsGraph(g) )
>>        {
>>            if ( ! alwaysSilent && ! update.isSilent() )
>>                error("Graph store already contains graph : "+g) ;
>>            return ;
>>        }
>>        // In-memory specific
>>        graphStore.addGraph(g, GraphFactory.createDefaultGraph()) ;
>>    }
>>
>>...and I need a...
>>
>>    if (deny(...)) {
>>        error("update create denied");
>>        return;
>>
>>Also need it too work whether the graphStore was from a Dataset or TDB...
>>ideally... :-)
>>
>>Regards Dick.
>

Reply via email to