adding additionals content viewers

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

adding additionals content viewers

Juan Sequeiros
Good morning,

How involved is it to add an additional content viewer for a mime type?
Our quick preliminary research leads us to modifying a few pieces of
framework.

Is this right path?  Has anyone been able to add an additional mime type to
be viewed under provenance "view" function?

Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: adding additionals content viewers

Joe Witt
At present it is not designed as a clearly API separated extension
point like processors or controller services and the like.  It might
make more sense to enable integration to an external viewer
service/capability than to make it a first class extension point.
But, for now, it requires internal changes and a custom build.

thanks

On Wed, May 17, 2017 at 9:35 AM, Juan Sequeiros <[hidden email]> wrote:

> Good morning,
>
> How involved is it to add an additional content viewer for a mime type?
> Our quick preliminary research leads us to modifying a few pieces of
> framework.
>
> Is this right path?  Has anyone been able to add an additional mime type to
> be viewed under provenance "view" function?
>
> Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: adding additionals content viewers

Juan Sequeiros
Thanks Joe.

For community:

You did bring up a good point about external viewer and what we actually
ended up doing was run a subset of the mime.type to and ExecuteStream
processor that could convert it to text and then we UpdateAttribute to
mime.type = text/plain > Then auto terminate success.

Then we can view the provenance event of the success out of the
UpdateAttribute.

The use requirement to view other mime types was mainly for troubleshooting
purposes so the flow I described above will work for us.

On Wed, May 17, 2017 at 9:38 AM Joe Witt <[hidden email]> wrote:

> At present it is not designed as a clearly API separated extension
> point like processors or controller services and the like.  It might
> make more sense to enable integration to an external viewer
> service/capability than to make it a first class extension point.
> But, for now, it requires internal changes and a custom build.
>
> thanks
>
> On Wed, May 17, 2017 at 9:35 AM, Juan Sequeiros <[hidden email]>
> wrote:
> > Good morning,
> >
> > How involved is it to add an additional content viewer for a mime type?
> > Our quick preliminary research leads us to modifying a few pieces of
> > framework.
> >
> > Is this right path?  Has anyone been able to add an additional mime type
> to
> > be viewed under provenance "view" function?
> >
> > Thank you.
>
Reply | Threaded
Open this post in threaded view
|

Re: adding additionals content viewers

Matt Gilman
I just wanted to clarify that additional content viewers can be added to
existing builds without internal changes or a custom NiFi build. Content
viewers (and Custom UIs) are discovered at start up in a similar to how
Processors are discovered. A content viewer can be bundled in any NAR and
each is associated with one or more content types [1]. When a matching
content type is encountered, the content viewer will be allowed to generate
the view which will be included in the response. Here are the two examples
that are included in NiFi [2] [3].

Thanks

Matt

[1]
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-content-viewer/src/main/webapp/META-INF/nifi-content-viewer
[2]
https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-content-viewer
[3]
https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-media-bundle/nifi-image-viewer

On Wed, May 17, 2017 at 12:32 PM, Juan Sequeiros <[hidden email]>
wrote:

> Thanks Joe.
>
> For community:
>
> You did bring up a good point about external viewer and what we actually
> ended up doing was run a subset of the mime.type to and ExecuteStream
> processor that could convert it to text and then we UpdateAttribute to
> mime.type = text/plain > Then auto terminate success.
>
> Then we can view the provenance event of the success out of the
> UpdateAttribute.
>
> The use requirement to view other mime types was mainly for troubleshooting
> purposes so the flow I described above will work for us.
>
> On Wed, May 17, 2017 at 9:38 AM Joe Witt <[hidden email]> wrote:
>
> > At present it is not designed as a clearly API separated extension
> > point like processors or controller services and the like.  It might
> > make more sense to enable integration to an external viewer
> > service/capability than to make it a first class extension point.
> > But, for now, it requires internal changes and a custom build.
> >
> > thanks
> >
> > On Wed, May 17, 2017 at 9:35 AM, Juan Sequeiros <[hidden email]>
> > wrote:
> > > Good morning,
> > >
> > > How involved is it to add an additional content viewer for a mime type?
> > > Our quick preliminary research leads us to modifying a few pieces of
> > > framework.
> > >
> > > Is this right path?  Has anyone been able to add an additional mime
> type
> > to
> > > be viewed under provenance "view" function?
> > >
> > > Thank you.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: adding additionals content viewers

Joe Witt
wow - i think i need to learn more about this NiFi thing.  That is awesome!

On Wed, May 17, 2017 at 1:15 PM, Matt Gilman <[hidden email]> wrote:

> I just wanted to clarify that additional content viewers can be added to
> existing builds without internal changes or a custom NiFi build. Content
> viewers (and Custom UIs) are discovered at start up in a similar to how
> Processors are discovered. A content viewer can be bundled in any NAR and
> each is associated with one or more content types [1]. When a matching
> content type is encountered, the content viewer will be allowed to generate
> the view which will be included in the response. Here are the two examples
> that are included in NiFi [2] [3].
>
> Thanks
>
> Matt
>
> [1]
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-content-viewer/src/main/webapp/META-INF/nifi-content-viewer
> [2]
> https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-content-viewer
> [3]
> https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-media-bundle/nifi-image-viewer
>
> On Wed, May 17, 2017 at 12:32 PM, Juan Sequeiros <[hidden email]>
> wrote:
>
>> Thanks Joe.
>>
>> For community:
>>
>> You did bring up a good point about external viewer and what we actually
>> ended up doing was run a subset of the mime.type to and ExecuteStream
>> processor that could convert it to text and then we UpdateAttribute to
>> mime.type = text/plain > Then auto terminate success.
>>
>> Then we can view the provenance event of the success out of the
>> UpdateAttribute.
>>
>> The use requirement to view other mime types was mainly for troubleshooting
>> purposes so the flow I described above will work for us.
>>
>> On Wed, May 17, 2017 at 9:38 AM Joe Witt <[hidden email]> wrote:
>>
>> > At present it is not designed as a clearly API separated extension
>> > point like processors or controller services and the like.  It might
>> > make more sense to enable integration to an external viewer
>> > service/capability than to make it a first class extension point.
>> > But, for now, it requires internal changes and a custom build.
>> >
>> > thanks
>> >
>> > On Wed, May 17, 2017 at 9:35 AM, Juan Sequeiros <[hidden email]>
>> > wrote:
>> > > Good morning,
>> > >
>> > > How involved is it to add an additional content viewer for a mime type?
>> > > Our quick preliminary research leads us to modifying a few pieces of
>> > > framework.
>> > >
>> > > Is this right path?  Has anyone been able to add an additional mime
>> type
>> > to
>> > > be viewed under provenance "view" function?
>> > >
>> > > Thank you.
>> >
>>
Reply | Threaded
Open this post in threaded view
|

Re: adding additionals content viewers

Michael Moser
I was going to add a JIRA to add this to the Developer's Guide, but I
see [1] one already exists.

-- Mike

[1] - https://issues.apache.org/jira/browse/NIFI-479


On Wed, May 17, 2017 at 1:18 PM, Joe Witt <[hidden email]> wrote:

> wow - i think i need to learn more about this NiFi thing.  That is awesome!
>
> On Wed, May 17, 2017 at 1:15 PM, Matt Gilman <[hidden email]> wrote:
>> I just wanted to clarify that additional content viewers can be added to
>> existing builds without internal changes or a custom NiFi build. Content
>> viewers (and Custom UIs) are discovered at start up in a similar to how
>> Processors are discovered. A content viewer can be bundled in any NAR and
>> each is associated with one or more content types [1]. When a matching
>> content type is encountered, the content viewer will be allowed to generate
>> the view which will be included in the response. Here are the two examples
>> that are included in NiFi [2] [3].
>>
>> Thanks
>>
>> Matt
>>
>> [1]
>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-content-viewer/src/main/webapp/META-INF/nifi-content-viewer
>> [2]
>> https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-content-viewer
>> [3]
>> https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-media-bundle/nifi-image-viewer
>>
>> On Wed, May 17, 2017 at 12:32 PM, Juan Sequeiros <[hidden email]>
>> wrote:
>>
>>> Thanks Joe.
>>>
>>> For community:
>>>
>>> You did bring up a good point about external viewer and what we actually
>>> ended up doing was run a subset of the mime.type to and ExecuteStream
>>> processor that could convert it to text and then we UpdateAttribute to
>>> mime.type = text/plain > Then auto terminate success.
>>>
>>> Then we can view the provenance event of the success out of the
>>> UpdateAttribute.
>>>
>>> The use requirement to view other mime types was mainly for troubleshooting
>>> purposes so the flow I described above will work for us.
>>>
>>> On Wed, May 17, 2017 at 9:38 AM Joe Witt <[hidden email]> wrote:
>>>
>>> > At present it is not designed as a clearly API separated extension
>>> > point like processors or controller services and the like.  It might
>>> > make more sense to enable integration to an external viewer
>>> > service/capability than to make it a first class extension point.
>>> > But, for now, it requires internal changes and a custom build.
>>> >
>>> > thanks
>>> >
>>> > On Wed, May 17, 2017 at 9:35 AM, Juan Sequeiros <[hidden email]>
>>> > wrote:
>>> > > Good morning,
>>> > >
>>> > > How involved is it to add an additional content viewer for a mime type?
>>> > > Our quick preliminary research leads us to modifying a few pieces of
>>> > > framework.
>>> > >
>>> > > Is this right path?  Has anyone been able to add an additional mime
>>> type
>>> > to
>>> > > be viewed under provenance "view" function?
>>> > >
>>> > > Thank you.
>>> >
>>>
Reply | Threaded
Open this post in threaded view
|

Re: adding additionals content viewers

Andrew Lim
I assigned NIFI-479 to myself and will work on it.  Definitely a cool feature to highlight in the docs!

-Drew


> On May 17, 2017, at 1:26 PM, Michael Moser <[hidden email]> wrote:
>
> I was going to add a JIRA to add this to the Developer's Guide, but I
> see [1] one already exists.
>
> -- Mike
>
> [1] - https://issues.apache.org/jira/browse/NIFI-479
>
>
> On Wed, May 17, 2017 at 1:18 PM, Joe Witt <[hidden email]> wrote:
>> wow - i think i need to learn more about this NiFi thing.  That is awesome!
>>
>> On Wed, May 17, 2017 at 1:15 PM, Matt Gilman <[hidden email]> wrote:
>>> I just wanted to clarify that additional content viewers can be added to
>>> existing builds without internal changes or a custom NiFi build. Content
>>> viewers (and Custom UIs) are discovered at start up in a similar to how
>>> Processors are discovered. A content viewer can be bundled in any NAR and
>>> each is associated with one or more content types [1]. When a matching
>>> content type is encountered, the content viewer will be allowed to generate
>>> the view which will be included in the response. Here are the two examples
>>> that are included in NiFi [2] [3].
>>>
>>> Thanks
>>>
>>> Matt
>>>
>>> [1]
>>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-content-viewer/src/main/webapp/META-INF/nifi-content-viewer
>>> [2]
>>> https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-content-viewer
>>> [3]
>>> https://github.com/apache/nifi/tree/master/nifi-nar-bundles/nifi-media-bundle/nifi-image-viewer
>>>
>>> On Wed, May 17, 2017 at 12:32 PM, Juan Sequeiros <[hidden email]>
>>> wrote:
>>>
>>>> Thanks Joe.
>>>>
>>>> For community:
>>>>
>>>> You did bring up a good point about external viewer and what we actually
>>>> ended up doing was run a subset of the mime.type to and ExecuteStream
>>>> processor that could convert it to text and then we UpdateAttribute to
>>>> mime.type = text/plain > Then auto terminate success.
>>>>
>>>> Then we can view the provenance event of the success out of the
>>>> UpdateAttribute.
>>>>
>>>> The use requirement to view other mime types was mainly for troubleshooting
>>>> purposes so the flow I described above will work for us.
>>>>
>>>> On Wed, May 17, 2017 at 9:38 AM Joe Witt <[hidden email]> wrote:
>>>>
>>>>> At present it is not designed as a clearly API separated extension
>>>>> point like processors or controller services and the like.  It might
>>>>> make more sense to enable integration to an external viewer
>>>>> service/capability than to make it a first class extension point.
>>>>> But, for now, it requires internal changes and a custom build.
>>>>>
>>>>> thanks
>>>>>
>>>>> On Wed, May 17, 2017 at 9:35 AM, Juan Sequeiros <[hidden email]>
>>>>> wrote:
>>>>>> Good morning,
>>>>>>
>>>>>> How involved is it to add an additional content viewer for a mime type?
>>>>>> Our quick preliminary research leads us to modifying a few pieces of
>>>>>> framework.
>>>>>>
>>>>>> Is this right path?  Has anyone been able to add an additional mime
>>>> type
>>>>> to
>>>>>> be viewed under provenance "view" function?
>>>>>>
>>>>>> Thank you.
>>>>>
>>>>