Scripted controllers

[Sumanth Chinthagunta <xm...@gmail.com>]

Since we have scripted processors, any plans to support scripted controllers in the roadmap?

-sumo

Re: Scripted controllers

[xm...@gmail.com]

Was planing to upgrade my websocket processor/controller  to 0.5.1.
Just checking, so that I don't have to build if controller scripting is in roadmap, Nothing important ....
Thanks 
Sumo

> On Feb 20, 2016, at 10:40 AM, Joe Witt <jo...@gmail.com> wrote:
> 
> Hello Sumo
> 
> https://issues.apache.org/jira/browse/NIFI-1458
> 
> That is to allow for scripted reporting tasks.
> 
> No plans for scripted controller services yet.  What do you have in mind?
> 
> Thanks
> Joe
>> On Feb 20, 2016 1:26 PM, "Sumanth Chinthagunta" <xm...@gmail.com> wrote:
>> 
>> Since we have scripted processors, any plans to support scripted
>> controllers in the roadmap?
>> 
>> -sumo

Re: Scripted controllers

[Matt Burgess <ma...@gmail.com>]

Sumo et al,

I thought about scripted Controller Services when I added NIFI-1458 for
scripting reporting tasks. The thing I ran into was that Processors and
Reporting Tasks are technically "consumers", at least in the sense that no
other NiFi "object" knows about their interfaces, innards, etc. Controller
Services are "producers", in the sense that the consumers need to know
about them (and their dependencies) beforehand, or at least the APIs.

For example, the InvokeHttp processor is built into a NAR while declaring a
dependency on the ssl-context-service-api, so they have a compile-time
dependency on the SSLContextService interface. For scripted controller
services, the objects that would use them (presumably scripted processors)
would need to have runtime access to the scripted controller services'
classloaders as they wouldn't have a priori knowledge of the controller
service's interface, and with the NAR setup it doesn't seem available at
runtime.  However ControllerService implementations are loaded via
ServiceLoader, which also makes it a bit harder for scripted CS impls. I
would think some classloader black-magic could be done for such a thing,
but haven't tried it yet.

Having said all that, you can use an existing ControllerService from a
scripting processor. The trick/rule is whether you have access to the
Objects referred to in the ControllerService's interface. For example, with
ExecuteScript (using Groovy) you can get access to a DBCPConnectionPool by
name and do SQL things with it, since the API is part of the normal Java
runtime. I will put together a blog post about this to illustrate, and will
include the above notes.

If you have ideas about how to do a scripted Controller Service, I am
definitely all ears :) There are probably two opportunities: 1) a scripted
impl of an existing interface, and 2) a new scripted ControllerService impl
that could be used in other (presumably scripted) processors.  I welcome
all thoughts, comments, questions, and suggestions!

Regards,
Matt

On Sat, Feb 20, 2016 at 1:40 PM, Joe Witt <jo...@gmail.com> wrote:

> Hello Sumo
>
> https://issues.apache.org/jira/browse/NIFI-1458
>
> That is to allow for scripted reporting tasks.
>
> No plans for scripted controller services yet.  What do you have in mind?
>
> Thanks
> Joe
> On Feb 20, 2016 1:26 PM, "Sumanth Chinthagunta" <xm...@gmail.com> wrote:
>
> > Since we have scripted processors, any plans to support scripted
> > controllers in the roadmap?
> >
> > -sumo
>

Re: Scripted controllers

[Joe Witt <jo...@gmail.com>]

Hello Sumo

https://issues.apache.org/jira/browse/NIFI-1458

That is to allow for scripted reporting tasks.

No plans for scripted controller services yet.  What do you have in mind?

Thanks
Joe
On Feb 20, 2016 1:26 PM, "Sumanth Chinthagunta" <xm...@gmail.com> wrote:

> Since we have scripted processors, any plans to support scripted
> controllers in the roadmap?
>
> -sumo