NIFI-13575 Improve Jetty Server handling of Web App Exceptions

[exceptionfactory]

Summary

NIFI-13575 Enables the throwUnavailableOnStartupException property for configured Web Applications in the framework Jetty Server. This property instructs Jetty to throw exceptions caught when starting a configured Web Applications, instead of just capturing and storing the exception. This approach removes the need for iterating over configured Jetty Server Handlers, and avoids potential issues related to nested handlers, ensuring that a Web Application exception will cause the Jetty Server to shutdown instead of continuing the startup process.

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 mvn clean install -P contrib-check
  • JDK 21

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

[bbende]

Code looks good and verified the original scenario of failing to fetch parameters from a parameter provider now fails start up.

I noticed there is still a code block for extension UIs that is checking the context for the unavailable exception:
https://github.com/apache/nifi/blob/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-jetty/src/main/java/org/apache/nifi/web/server/JettyServer.java#L375-L382

It seems like the previous intent of the code was to not fail start up for extension UIs that failed to start, and instead just log a warning, but now since all of them go through the loadWar helper method, I think a failed extension UI would also throw the exception and fail start up. Just wanted to get your thoughts on that before proceeding.

[exceptionfactory]

Thanks for the review @bbende.

That's a very good point regarding failure handling for extension applications. I pushed a changed enumerating the required contexts paths, and adjusted setting of the throw exceptions property based on whether the context is a required framework path.

[bbende]

The latest updated looks good, I'll wait for the builds to complete and then merge if they pass