Branch: refs/heads/master Home: https://github.com/xwiki/xwiki-platform Commit: 0732dc45bd812cb29937df175808a9aec562e22d https://github.com/xwiki/xwiki-platform/commit/0732dc45bd812cb29937df175808a... Author: Vincent Massol <[email protected]> Date: 2026-08-07 (Fri, 07 Aug 2026) Changed paths: M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/plugin/packaging/Package.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/stats/impl/xwiki/XWikiStatsStoreService.java M xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/store/hibernate/HibernateAttachmentVersioningStore.java Log Message: ----------- XWIKI-24665: Apply the logging best practices across commons, rendering and platform (#6113) * XWIKI-24665: Apply the logging best practices across commons, rendering and platform * Revert the log level change on the stop order of the statistics storing thread: it goes back to warn, and the throwable comes back with it * Do not restore the isInfoEnabled() guard that used to wrap it. That guard was a bug: it tested the info level while the statement logged at warn, so the message was dropped whenever warn was enabled and info was not. Removing it rather than correcting it to isWarnEnabled() keeps the statement free of a guard SLF4J already applies itself * Restore the throwable of the two interrupted-thread warnings in the same class, which the earlier pass over the warn() calls missed. They kept the same shape as the 106 already fixed: the root cause formatted into the message instead of the throwable passed as the last argument. The class was inconsistent as a result, since the third site logging the very same InterruptedException still passed it Co-authored-by: Claude Opus 5 (1M context) <[email protected]> * XWIKI-24665: Apply the logging best practices across commons, rendering and platform * Restore the throwable when deleting an attachment archive fails, the last site the earlier pass over the warn() calls missed. Unlike the interrupted-thread warnings, here the trace is the diagnosis: the statement catches every Exception coming out of a Hibernate write, and the root cause message alone does not say which one * Keep the {} placeholders the sweep introduced in place of String.format Co-authored-by: Claude Opus 5 (1M context) <[email protected]> * XWIKI-24665: Apply the logging best practices across commons, rendering and platform * Restore the error plus debug pair the sweep collapsed into a single error() when deleting the previous document of a package fails, the third occurrence of that collapse and the one left unresolved. The pair is deliberate: this runs once per document of the package, so a trace for every failure floods the log of a large import, while the trace stays reachable by raising the level * State that reason inline, since nothing in the code says why the trace is at debug * Keep the {} placeholder the sweep introduced in place of the string concatenation, through a local variable so that the message is not duplicated as a literal Co-authored-by: Claude Opus 5 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 5 (1M context) <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki/xwiki-platform/settings/notifications