The plugin logs everything through Bukkit.getLogger(), the root logger, instead of the getLogger() it inherits from JavaPlugin. There are 63 such calls in src/main/java (31 severe, 5 warning, 25 info) and zero uses of the plugin's own logger.
plugin.yml sets prefix: SH2, but that prefix belongs to the plugin logger. Root-logger lines never get it, so a line the plugin wrote is indistinguishable from any other server output.
From a green end-to-end run (run/logs/latest.log):
[09:59:19] [Server thread/INFO]: [SH2] Enabling SetHomesTwo v1.2.2
[09:59:19] [Server thread/INFO]: Homes database connection was successful.
The first line is Bukkit's, written through the plugin logger. The second is ours, SetHomesTwo.java:103, written through the root logger: no prefix, no plugin name.
Why it matters
- A server owner reading a few thousand lines of log cannot tell which errors came from this plugin, and neither can we when one is pasted into a bug report.
- The end-to-end suite's
boot.spec.ts test "the plugin starts without logging an error" filters the log to lines containing SetHomesTwo or [SH2], so it drops every error the plugin raises itself. It still catches Paper's load and enable failures, which is the likeliest regression for a shaded jar, but it would stay green through a swallowed database error. That test cannot be made honest without either this change or exclusion-based detection, which is much more fragile.
Fix
Mechanical: replace Bukkit.getLogger() with the plugin's own logger, reaching it through SetHomesTwo.instance().getLogger() from static contexts. Worth checking whether any call site runs before the instance is available, and tightening boot.spec.ts once the prefix is reliable.
The plugin logs everything through
Bukkit.getLogger(), the root logger, instead of thegetLogger()it inherits fromJavaPlugin. There are 63 such calls insrc/main/java(31severe, 5warning, 25info) and zero uses of the plugin's own logger.plugin.ymlsetsprefix: SH2, but that prefix belongs to the plugin logger. Root-logger lines never get it, so a line the plugin wrote is indistinguishable from any other server output.From a green end-to-end run (
run/logs/latest.log):The first line is Bukkit's, written through the plugin logger. The second is ours,
SetHomesTwo.java:103, written through the root logger: no prefix, no plugin name.Why it matters
boot.spec.tstest "the plugin starts without logging an error" filters the log to lines containingSetHomesTwoor[SH2], so it drops every error the plugin raises itself. It still catches Paper's load and enable failures, which is the likeliest regression for a shaded jar, but it would stay green through a swallowed database error. That test cannot be made honest without either this change or exclusion-based detection, which is much more fragile.Fix
Mechanical: replace
Bukkit.getLogger()with the plugin's own logger, reaching it throughSetHomesTwo.instance().getLogger()from static contexts. Worth checking whether any call site runs before the instance is available, and tighteningboot.spec.tsonce the prefix is reliable.