Separating custom service API from its implementation

[Tim Dean <ti...@gmail.com>]

We’ve got a handful of custom NiFi controller services. The documentation describes how to properly separate the API of a custom service from its implementation using different NAR files. When we don’t do that, we see a message that says the following:

org.apache.nifi.nar.ExtensionManager Controller Service x.x.x.x.MyControllerServiceApi is bundled with its supporting APIs x.x.x.x.MyControllerServiceImpl. The service APIs should not be bundled with the implementations.

This warning makes sense, and I know how to fix it. I am trying to understand if fixing it is really worth the effort. This seems to work for us as is, even though it is clearly wrong according to the NiFi documentation. I assume that this approach will fail under some circumstances, but I don’t know when or how it will fail.

Can anyone provide any background on the downsides of leaving our controller service implementations in the same NAR file as their APIs?

Thanks

Re: Separating custom service API from its implementation

[Tim Dean <ti...@gmail.com>]

Thanks Bryan - That makes sense

-Tim

> On Jul 30, 2018, at 2:45 PM, Bryan Bende <bb...@gmail.com> wrote:
> 
> Tim,
> 
> In the case where it is your own custom service api and service impl,
> and you know you are never going to have another implementation of the
> API, then it doesn't really matter and having them all in one NAR will
> work.
> 
> The issue is that by bundling the implementation with the API, now
> someone else who wants to provide a different implementation is forced
> to inherit the classpath of your other implementation.
> 
> By separating them, each implementation only depends on the API and
> doesn't need to worry about each other's specific implementation
> dependencies.
> 
> Thanks,
> 
> Bryan
> 
> 
> On Mon, Jul 30, 2018 at 2:35 PM, Tim Dean <ti...@gmail.com> wrote:
>> We’ve got a handful of custom NiFi controller services. The documentation
>> describes how to properly separate the API of a custom service from its
>> implementation using different NAR files. When we don’t do that, we see a
>> message that says the following:
>> 
>> org.apache.nifi.nar.ExtensionManager Controller Service
>> x.x.x.x.MyControllerServiceApi is bundled with its supporting APIs
>> x.x.x.x.MyControllerServiceImpl. The service APIs should not be bundled with
>> the implementations.
>> 
>> 
>> This warning makes sense, and I know how to fix it. I am trying to
>> understand if fixing it is really worth the effort. This seems to work for
>> us as is, even though it is clearly wrong according to the NiFi
>> documentation. I assume that this approach will fail under some
>> circumstances, but I don’t know when or how it will fail.
>> 
>> Can anyone provide any background on the downsides of leaving our controller
>> service implementations in the same NAR file as their APIs?
>> 
>> Thanks

Re: Separating custom service API from its implementation

[Bryan Bende <bb...@gmail.com>]

Tim,

In the case where it is your own custom service api and service impl,
and you know you are never going to have another implementation of the
API, then it doesn't really matter and having them all in one NAR will
work.

The issue is that by bundling the implementation with the API, now
someone else who wants to provide a different implementation is forced
to inherit the classpath of your other implementation.

By separating them, each implementation only depends on the API and
doesn't need to worry about each other's specific implementation
dependencies.

Thanks,

Bryan


On Mon, Jul 30, 2018 at 2:35 PM, Tim Dean <ti...@gmail.com> wrote:
> We’ve got a handful of custom NiFi controller services. The documentation
> describes how to properly separate the API of a custom service from its
> implementation using different NAR files. When we don’t do that, we see a
> message that says the following:
>
> org.apache.nifi.nar.ExtensionManager Controller Service
> x.x.x.x.MyControllerServiceApi is bundled with its supporting APIs
> x.x.x.x.MyControllerServiceImpl. The service APIs should not be bundled with
> the implementations.
>
>
> This warning makes sense, and I know how to fix it. I am trying to
> understand if fixing it is really worth the effort. This seems to work for
> us as is, even though it is clearly wrong according to the NiFi
> documentation. I assume that this approach will fail under some
> circumstances, but I don’t know when or how it will fail.
>
> Can anyone provide any background on the downsides of leaving our controller
> service implementations in the same NAR file as their APIs?
>
> Thanks