You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Juan Sequeiros <he...@gmail.com> on 2017/05/17 13:35:03 UTC
adding additionals content viewers
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.
Re: adding additionals content viewers
Posted by Andrew Lim <an...@gmail.com>.
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 <mo...@gmail.com> 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 <jo...@gmail.com> 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 <ma...@gmail.com> 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 <he...@gmail.com>
>>> 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 <jo...@gmail.com> 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 <he...@gmail.com>
>>>>> 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.
>>>>>
>>>>
Re: adding additionals content viewers
Posted by Michael Moser <mo...@gmail.com>.
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 <jo...@gmail.com> 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 <ma...@gmail.com> 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 <he...@gmail.com>
>> 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 <jo...@gmail.com> 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 <he...@gmail.com>
>>> > 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.
>>> >
>>>
Re: adding additionals content viewers
Posted by Joe Witt <jo...@gmail.com>.
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 <ma...@gmail.com> 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 <he...@gmail.com>
> 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 <jo...@gmail.com> 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 <he...@gmail.com>
>> > 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.
>> >
>>
Re: adding additionals content viewers
Posted by Matt Gilman <ma...@gmail.com>.
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 <he...@gmail.com>
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 <jo...@gmail.com> 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 <he...@gmail.com>
> > 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.
> >
>
Re: adding additionals content viewers
Posted by Juan Sequeiros <he...@gmail.com>.
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 <jo...@gmail.com> 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 <he...@gmail.com>
> 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.
>
Re: adding additionals content viewers
Posted by Joe Witt <jo...@gmail.com>.
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 <he...@gmail.com> 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.