[pull] master from apache:master - #641
Merged
Merged
Conversation
…nted label
### What is this PR for?
In the HDFS file interpreter, `listOne()` appends a hard-coded `GMT` label to the
modification time, but `listDate()` formats the timestamp using the JVM default
time zone. On any server not running in UTC, the displayed value does not match
the label (e.g. a file modified at `2015-08-02 20:43` GMT is shown as
`2015-08-03 05:43GMT` on a KST server).
This PR sets the formatter's time zone to GMT in `listDate()` so the rendered
value matches the existing label.
Why format in GMT (option A) rather than keep local time and fix the label (option B):
- `modificationTime` is an absolute epoch value, so the time zone is only a
display choice. Formatting in GMT keeps the output identical regardless of the
host/JVM default zone and consistent with the label already printed.
- Showing the interpreter JVM's local time would be ambiguous in shared HDFS /
remote-interpreter, multi-user setups ("whose local time?"), and the output
would vary per deployment, making it harder to reproduce and test.
### What type of PR is it?
Bug Fix
### Todos
* [x] - Format the modification time in GMT in `listDate()`
* [x] - Add a regression test that runs under a non-UTC default zone (`Asia/Seoul`) and asserts the value is rendered in GMT to match the label
### What is the Jira issue?
* https://issues.apache.org/jira/browse/ZEPPELIN-6483
### How should this be tested?
* `./mvnw test -pl file -Dtest=HDFSFileInterpreterTest`
* The new test `testListDateFormatsInGmtToMatchLabel` pins a known `modificationTime` (1438548219672 = 2015-08-02 20:43 GMT) under an `Asia/Seoul` default zone and asserts the output contains `2015-08-02 20:43GMT`.
### Screenshots (if appropriate)
N/A
### Questions:
* Does the license files need to update? No
* Is there breaking changes for older versions? No — display-only change; on non-UTC servers the shown value changes, but it now correctly matches the label
* Does this needs documentation? No
Closes #5351 from dev-donghwan/ZEPPELIN-6483.
Signed-off-by: ChanHo Lee <chanholee@apache.org>
…erpreter numeric properties
### What is this PR for?
`MongoDbInterpreter.open()` parses two numeric properties, `mongo.shell.command.timeout` and `mongo.interpreter.concurrency.max`, with `Long.parseLong()` / `Integer.parseInt()` outside any `try`/`catch` — the existing try-with-resources in that method covers only the `Scanner` that loads the shell extension. When either value is empty, missing, or non-numeric, a raw `NumberFormatException` escapes `open()`.
Because `open()` is triggered lazily by the first paragraph run, this lands in the notebook paragraph as a bare stack trace that never names the property at fault. The MongoDB interpreter has several numeric properties, so the only way to tell which one failed today is to read the line number off the trace and open the source — which is not something a Zeppelin user should have to do.
Reproduced on JDK 11: an empty value yields `NumberFormatException: For input string: ""`, a non-numeric value yields `For input string: "60s"`, and a missing property yields a message of just `null`. One note on that last case — the issue describes it as `Cannot parse null string`, but that wording comes from newer JDKs. On the JDK 11 this project builds with, `Long.parseLong(null)` throws `NumberFormatException("null")`, so the message carries even less information than the issue suggests.
### What does this PR do?
- Wraps each parse and re-throws the `NumberFormatException` as an `InterpreterException` that names the property and its invalid value, keeping the original exception as the cause:
```
Invalid value for property 'mongo.shell.command.timeout': 60s
```
- Keeps the two parses separate so the message always points at the exact property that failed.
- Adds `throws InterpreterException` to the `open()` override. The base `Interpreter.open()` already declares it, so no caller contract changes — at runtime the call goes through `LazyOpenInterpreter.open()`, which already declares it too, and the only direct caller was the test.
Per the issue, the scope is deliberately narrow: no range validation, no silent fallback to default values, no unrelated changes. An invalid configuration still fails exactly as before; it just fails understandably.
### What type of PR is it?
Improvement
### What is the Jira issue?
* https://issues.apache.org/jira/browse/ZEPPELIN-6474
### How should this be tested?
* `./mvnw test -pl mongodb`
* Four tests were added to the existing `MongoDbInterpreterTest`, covering both properties across the three failure modes named in the issue: non-numeric and missing for `mongo.shell.command.timeout`, empty and missing for `mongo.interpreter.concurrency.max`. Each asserts that an `InterpreterException` is thrown, that its message names the offending property, and that the original `NumberFormatException` is preserved as the cause. The two remaining combinations exercise the identical catch block, so they were left out rather than duplicated.
* `MongoDbInterpreterTest.init()` now declares `throws InterpreterException`, since it calls `open()` on the concrete type.
* To confirm the new tests are meaningful, I reverted the change to `MongoDbInterpreter` and re-ran the suite: exactly the four new tests fail with `expected: <InterpreterException> but was: <NumberFormatException>`, while the two pre-existing tests still pass. With the change applied, all six pass.
### Questions:
* Does the license files need to update? No
* Is there breaking changes for older versions? No — a valid configuration behaves exactly as before, and an invalid one already failed. Only the exception type and its message change.
* Does this needs documentation? No
Closes #5356 from sylee6529/ZEPPELIN-6474-mongodb-numberformat.
Signed-off-by: ChanHo Lee <chanholee@apache.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )