[
https://issues.apache.org/jira/browse/NIFI-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375101#comment-14375101
]
Joseph Witt commented on NIFI-353:
----------------------------------
Matt,
Review feedback provided. I pulled/clean build off nifi-353 branch:
1) Looks good. Did notice a surprising delay when selecting view raw. Made me
wonder if it was loading the whole object in memory server side before replying
back to the content. My guess is that for viewing raw (at least) we'll need to
consider pagination at some point.
2) After viewing the content of an object and going back to the nifi graph to
make changes i received this notice:
"Given revision [9, 3e1ad7ec-a96a-47dc-af7e-f2f97ca9b344] does not match
current revision [0, ]."
Once I refreshed I was good to go again. Did not expect that. Do you?
3) After viewing an XML document. I then ran it through replace text and gave
it a JSON document. In bringing up the viewer it assumed it was an XML
document which is fair since the filename was still .xml. When selecting to
view the formatted version i got this:
"HTTP ERROR 500
Problem accessing /nifi-content-viewer/. Reason:
Server Error
Caused by:
java.io.IOException: Unable to transform content as XML:
net.sf.saxon.trans.XPathException: org.xml.sax.SAXParseException; lineNumber:
1; columnNumber: 1; Content is not allowed in prolog.
at
org.apache.nifi.web.StandardContentViewerController.doGet(StandardContentViewerController.java:83)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:800)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)
at
org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330)
at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:108)
at
org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84)"
4) In viewing that JSON document which was claimed to be an XML document and
selecting HEX view the viewer immediately showed a very long line but was in a
rendering mode for more than a minute before i just closed that tab. And
interestingly the tab from which I clicked 'view' was no longer actionable
(could not click any buttons). But after closing that tab and navigating back
to nifi it appeared fine again.
5) So then I ran that JSON document through IdentifyMimeType. It now has the
attributes:
mime.extension = .txt
mime.type = text/plain
I then noticed that the JSON i copied has been duplicated *many times* over.
So it does indeed not appear to be a valid JSON document. So that is good at
least. But obviously we'll have to make sure the viewer is resilient to
lies/bad data/etc.. It is totally fine to fail to load the object and leave a
note. But hanging/etc.. is to be avoided if possible.
6) When i give it a proper JSON document with the mime.type set to
'application/json' it works great. Same is true of xml.
My sense is this is still fairly experimental. You could disable the link to
the viewer by default for now while we iterate on it over time. What do you
think? I can give my +1 to that idea.
Thanks
Joe
> 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)
