SeleniumHQ / SeleniumHQ/selenium
[Feature]: Migrate remaining getDebugLogLevel() call sites (and any other ad-hoc debug-log-level logic) to fixed logger levels
- Dominant language
- Java
- Stars
- 34.5k
- Forks
- 8.7k
- Avg merge
- 2d 1h
- Merged PRs (30d)
- 92
Description
### Feature and motivation
Follow-up from #17832 (part of the umbrella tracker, see linked issue), and the remaining scope of #12892 beyond unifying the two debug switches.
#17832 makes `-Dselenium.debug=true`, `-Dselenium.webdriver.verbose=true`, and `SE_DEBUG` all raise the real `org.openqa.selenium` JUL logger to `FINE`, so debug output is now consistently *visible* through the ordinary logging config regardless of which switch is used. What it deliberately does not do is migrate the ~64 existing call sites (across 14 files, per a repo-wide grep of `Debug.getDebugLogLevel()` under `java/src`) that still read `Debug.getDebugLogLevel()` to decide between reporting at `INFO` (debugging) or `FINE` (not debugging). Those call sites are now consistently *visible* under the new mechanism but not consistently *levelled* — they report at `INFO` instead of just logging at a fixed `FINE`/`FINER` and letting the real logger level (now meaningfully toggleable) do the filtering.
Scope for whoever picks this up — broader than just the `getDebugLogLevel()` call sites:
1. The ~64 `Debug.getDebugLogLevel()) call sites (14 files) — migrate each to a fixed severity (`Level.FINE` in the common case; preserve any that were deliberately logging at a different fixed level already, e.g. anything already tied to `FINER`/`FINEST`) and drop the `INFO`-while-debugging indirection entirely.
2. Any other ad-hoc "log more/differently when debugging" logic elsewhere in the Java bindings that isn't already going through `getDebugLogLevel()` — audit for methods that log anything and branch on `Debug.isDebugging()`/`Debug.isDebugAll()` directly rather than through the one sanctioned helper, so the standardization actually covers "every method that logs anything," not just the already-centralized call sites.
3. Once fully migrated, `Debug.getDebugLogLevel()` (already `@Deprecated(forRemoval = true)` as of #17832) has zero remaining callers and can be removed.
This is a purely mechanical migration once scoped — no new logging mechanism needed, #17832 already built that — but it touches enough files that it deserves its own PR(s) and review rather than folding into #17832 or #.
### Related
#12892, #17832 (see its "Follow-on work" note under Additional Considerations for the original scoping of the ~64-call-site count).
Contributor guide
Research direction
Start with a repo-wide search under java/src for Debug.getDebugLogLevel(), covering the roughly 64 call sites in 14 files, then audit direct Debug.isDebugging()/Debug.isDebugAll() logging branches. Replace the ad-hoc level selection with fixed severities while preserving deliberate FINER/FINEST cases; done means the helper has no callers and can be removed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- developer-experience
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100