[
https://issues.apache.org/jira/browse/NIFI-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14366418#comment-14366418
]
Matt Gilman commented on NIFI-353:
----------------------------------
So the ascii preview of the hex is being treated as HTML markup within the
hexview plugin. I modified their source to address this issue. I believe this
is ok according to their license (MIT). If this is a acceptable route I can
provide the fix back to them and use our modified version until its been
accepted/released. I've looked for other options and was not able to readily
find anything I liked better.
The '@' at the end is simply padding [1]. The plugin is rendering the padding
character '=' as '@' symbols. I could modify that as well for our use, but it
seems to be done deliberately. Not sure that's appropriate to contribute back
to them. Also, I'm pretty sure the plugin requires the input to be padded
appropriately.
[1] http://en.wikipedia.org/wiki/Base64#Padding
> Create a Data Viewer
> --------------------
>
> Key: NIFI-353
> URL: https://issues.apache.org/jira/browse/NIFI-353
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
> Reporter: Matt Gilman
> Assignee: Matt Gilman
> Attachments: flow_that_shows_issues_with_viewer.xml
>
>
> For use in property:
> {code}nifi.content.viewer.url{code}
> The content viewer will be extensible in that the supported mime types will
> be discovered at runtime. We will be taking an approach similar to Java SPI.
> During startup all war files will be inspected looking for a
> META-INF/nifi-data-viewer file. This file will contain the mime types that it
> can render (1 per line). Duplicate viewers will be logged and either the
> first or the last will be utilized.
> Currently, the content viewer is applicable for viewing archived data through
> the provenance UI. This will likely be expanded to integrate with other parts
> of the application where applicable (viewing content in queues, etc). When
> viewing the data, the content viewer controller will get the data stream and
> detect its type (Apache Tika, known mime type, file extension, etc). Will
> likely need to add support for decompressing/unpacking. Once the underlying
> type is known and is supported, the content viewer controller will generate
> the webpage and defer to the discovered web application to generate the mark
> up for the data (via RequestDispatcher.include). This means that the
> discovered web application does not need to generate any boilerplate HTML and
> all types of content will be viewed in a similar UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
