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 <moser...@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 <joe.w...@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 <matt.c.gil...@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 <helloj...@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 <joe.w...@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 <helloj...@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.
>>>>> 
>>>> 

Reply via email to