NIFI-15378 - Fix formatting for XML Content Viewer

[pvillard31]

Summary

NIFI-15378 - Fix formatting for XML Content Viewer

As a side note:

transformProvider.setOmitXmlDeclaration(true);

was introduced in NiFi 2 but was not there in NiFi 1. I'm removing it as I'm not sure why we would want to remove it.

Before change:

After change:

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[pvillard31]

As a note, I'm doing it this way instead of using """ to avoid checkstyle errors about trailing whitespaces when we are doing it on purpose for this specific test.

[exceptionfactory]

Thanks for addressing this issue @pvillard31.

On initial review, switching from the StreamSource the DOMSource is concerning, because it introduces potential resource consumption issues with reading the entire document into memory. That is the reason for the StreamSource approach.

Using the DocumentBuilderFactory directly, without the wrapper class from nifi-xml-processing is also a concern.

It looks like a different solution is needed that preserves the streaming strategy.

[exceptionfactory]

It seems like the particular issue relates to XML that is already formatted, thus having the white space text nodes. I haven't looked closely at the client-side rendering, but there might be an opportunity to adjustment on the frontend. In particular, since the Transformer has indenting enabled, perhaps disabling it could work, similar to how the frontend formats JSON.

[pvillard31]

I'm looking into improving the transformer using an identity xslt transformation to preserve the streaming capability and not hold the whole document in memory. Making some tests right now.

[pvillard31]

Pushed a commit with a different approach where I'm adding the transformation logic in the xml-processing bundle and I'm using an XSLT identity to remove the whitespaces/empty lines. I had to add an exclude for a spotbug warning. I used an annotation, let me know if you'd rather go with a proper exclude configuration file.

[exceptionfactory]

Thanks for the updated approach @pvillard31.

I don't think it is worth the additional complexity of the XSLT just to remove whitespace in this case. The Content Viewer is for presentation, and we definitely should avoid changing the nifi-xml-processing module for this purpose.

[exceptionfactory]

@pvillard31 Taking a quick look at the frontend configuration for CodeMirror, I'm wondering if the best solution is actually to remove reformatting on the server side and simply allow CodeMirror to handle formatting.

[exceptionfactory]

@pvillard31 Taking a quick look at the frontend configuration for CodeMirror, I'm wondering if the best solution is actually to remove reformatting on the server side and simply allow CodeMirror to handle formatting.

Actually that may not be an option without an additional library, so something on the server side is probably still needed.

[pvillard31]

OK, took a completely different approach given that we agree this is more of a pure frontend requirement. Let me know what you think.

Still same result:

[exceptionfactory]

Thanks @pvillard31, going in the direction of a frontend change looks much more streamlined. It looks like some of the backend changes can be reverted. I'm not sure about keeping the unit test, perhaps a more simplified version may still be useful, but it might be better to remove for now since it only relates to XML.

I will take a closer look at the frontend code changes.