[ZEPPELIN-6216] Show clear message when job manager is disabled instead of infinite loading

[devyeony]

This PR is a rebased version of #5022
The previous PR was automatically closed because the branch was deleted, so I recreated the branch and opened this new PR.

What is this PR for?

This PR fixes the issue that occurs when zeppelin.jobmanager.enable is set to false. In this case, the server sends no response, causing the Job Manager page in both classic and new UIs to show an infinite loading indicator. This behavior confuses users and gives the impression that the page is broken.

To improve user experience, this PR introduces explicit server-side handling that returns an explicit "not allowed" response when the Job Manager is disabled via configuration. Additionally, both classic and new UIs have been updated to properly handle this response and display a user-friendly message: "Job Manager is disabled in the current configuration."

This change ensures users are informed about the disabled state instead of encountering an endless loading screen.

What type of PR is it?

Improvement

Todos

• Implement server-side forbidden response when Job Manager is disabled
• Add JOB_MANAGER_DISABLED WebSocket message and corresponding handling in both Classic and New UI
• Add unit and integration tests covering the new behavior

Note:

• Although REST API tests have been implemented, the current frontend (both Classic and New UI) interacts with the Job Manager primarily through WebSocket communication. Therefore, the functional verification and actual handling of the "Job Manager disabled" scenario have been focused on the WebSocket path. The REST API tests are prepared to ensure future compatibility if the REST endpoints are used.
• In the user-request handling method, a ForbiddenException triggers sending a clear error message to the client so the UI can inform the user that the Job Manager is disabled. However, during broadcast events where no direct client request is involved, the exception is logged at debug level and silently skipped to avoid unnecessary noise or client interruptions.

What is the Jira issue?

[ZEPPELIN-6216]

How should this be tested?

• Automated tests have been added to cover the new behavior when the Job Manager is disabled:
  • Unit tests in JobManagerServiceTest verify that forbidden exceptions are thrown.
  • REST API tests in NotebookRestApiTest check that HTTP 403 responses with appropriate messages are returned.
  • WebSocket and server event handling tests in NotebookServerTest ensure no unexpected exceptions occur and proper notification messages are sent.
• Manual testing steps:
  1. Set zeppelin.jobmanager.enable to false via ZeppelinConfiguration.
  2. Access the Job Manager page in both classic and new UI.
  3. Confirm that instead of infinite loading, a clear message stating "Job Manager is disabled in the current configuration." is displayed.

Screenshots (if appropriate)

• AS-IS (New UI)

• AS-IS (Classic UI)

• TO-BE (New UI)

• TO-BE (Classic UI)

Questions:

• Does the license files need to update? No
• Is there breaking changes for older versions? No
• Does this needs documentation? No

[devyeony]

The original branch was deleted, so I recreated it and opened this new PR.
You can refer to the previous code review in #5022.
Sorry for the inconvenience.

I’ve rebased and merged up to the latest commits.

@Reamer
I’ve addressed all the points you mentioned in your review. I'd appreciate it if you could take a look when you have time. Thank you so much!

@tbonelee
I’ve addressed all the points you mentioned in your review, except for the issue regarding the ng-if="jobManagerEnabled" block inside the ng-if="isFilterLoaded" block. Could you take a look at that part when you have time? Thanks a lot!

[Reamer]

Backend Code LGTM
We need a review for the frontend part.

[tbonelee]

Frontend code LGTM.
I left a comment in the previous PR suggesting a change related to the ng-if block nesting.
It's a just code structure suggestion, not a logical issue, so feel free to share your thoughts on it.

[ParkGyeongTae]

I think this change will help reduce user confusion.

[devyeony]

@Reamer @tbonelee @ParkGyeongTae Thank you for your review and feedback.
@tbonelee Thank you for your valuable feedback. I will take a closer look at the points you mentioned.

[ParkGyeongTae]

@devyeony There are conflicts with master. Please rebase your branch on master and force-push to fix them.

[devyeony]

@ParkGyeongTae Conflicts with master were resolved via rebase and force-push.
The conflicts in job-manager.component.html were caused by formatting changes.
I applied the lint and formatting updates from ZEPPELIN-6287.

[Reamer]

We have a CI failure.

Error:  Failures: 
Error:    JobManagerServiceTest.shouldThrowForbiddenException_whenJobManagerIsDisabled:53 Expected org.apache.zeppelin.service.exception.JobManagerForbiddenException to be thrown, but nothing was thrown.

[devyeony]

@Reamer, thank you for your feedback on the parts I missed. I would appreciate it if you could take a look at this test code JobManagerServiceTest and share your thoughts when you have time.

⚠️ CI Failure Reason:
Initially, the code was designed to throw a JobManagerForbiddenException immediately when zeppelin.jobmanager.enable = false. After the code review, it was modified to return Collections.emptyList() and report the exception via the callback instead. The related test code was not updated to reflect this change, which caused the CI failure.

✨ Test Refactoring:
All tests for zeppelin.jobmanager.enable = false have been grouped under a @Nested class. This improves organization and readability compared to the previous version, making it easier to understand which tests correspond to the disabled JobManager scenario.

💡 Future Improvements:
While updating the test code, I identified a few areas for potential improvements. These are beyond the scope of this PR and were not included, but they could be addressed in follow-up work.

1. This PR focuses on the case when zeppelin.jobmanager.enable = false. Test cases for zeppelin.jobmanager.enable = true were not included in this PR and could be added in a future PR.
2. Currently, MockitoExtension is not applied in the project. As a result, we use @SuppressWarnings("unchecked") when creating generic mocks, which appears in other tests as well. In the future, we could refactor tests to use MockitoExtension and @Mock annotations for a more modern and type-safe style.

[Reamer]

LGTM

[tbonelee]

LGTM

[ParkGyeongTae]

LGTM 👍
Just to note, the CI failure in license-check (pull_request) is already fixed in another PR, so no problem.
See: #5047

[tbonelee]

Merged into master and branch-0.12