fix: drop dead logback ContextDetachingSCL listener from web.xml#2976
Merged
bjagg merged 1 commit intoMay 4, 2026
Merged
Conversation
Problem: uPortal-webapp/src/main/webapp/WEB-INF/web.xml registers ch.qos.logback.classic.selector.servlet.ContextDetachingSCL as a servlet context listener with the comment "Needed to remove JMX registration and allow for classloader GC. Should be first listener per http://logback.qos.ch/manual/loggingSeparation.html#hotDeploy". The class was part of Logback's J2EE selector machinery and was removed from Logback in 1.3.x. The listener has been a tripwire across the fleet during the 2026-05 release wave: every portlet that bumped Logback to 1.3+ via uportal-portlet-parent v51 hit ClassNotFoundException at context startup with this exact listener. uPortal core itself bundles Logback 1.5.32 today and would hit the same wall the moment its current "module-loading-warning-only" behavior tightens (or when Tomcat's StandardContext switches to strict listener loading). The listener also has no functional value here — Logback's modern auto-cleanup handles classloader GC and JMX deregistration without needing this hook. The original loggingSeparation guidance (the URL in the comment) was for using LoggerContextSelector with hot-deploy of separate webapps, which is not how this portal's logging is set up. Goal: clean up the dead config now so it isn't a tripwire later. Changes: - uPortal-webapp/src/main/webapp/WEB-INF/web.xml: remove the <listener>ContextDetachingSCL</listener> block plus its outdated explanatory comment. Notes: same listener removal pattern landing across the fleet (AnnouncementsPortlet, CalendarPortlet, JasigWidgetPortlets, NewsReaderPortlet, NotificationPortlet, SimpleContentPortlet) as a follow-up to the 2026-05 release wave.
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
`uPortal-webapp/src/main/webapp/WEB-INF/web.xml` registers `ch.qos.logback.classic.selector.servlet.ContextDetachingSCL` as a servlet context listener with the comment "Needed to remove JMX registration and allow for classloader GC. Should be first listener per http://logback.qos.ch/manual/loggingSeparation.html#hotDeploy".
The class was part of Logback's J2EE selector machinery and was removed from Logback in 1.3.x.
The listener has been a tripwire across the fleet during the 2026-05 release wave: every portlet that bumped Logback to 1.3+ via `uportal-portlet-parent` v51 hit `ClassNotFoundException` at context startup with this exact listener. uPortal core itself bundles Logback 1.5.32 today and would hit the same wall the moment its current "module-loading-warning-only" behavior tightens (or when Tomcat's `StandardContext` switches to strict listener loading).
The listener also has no functional value here — Logback's modern auto-cleanup handles classloader GC and JMX deregistration without needing this hook. The original `loggingSeparation` guidance (the URL in the comment) was for using `LoggerContextSelector` with hot-deploy of separate webapps, which is not how this portal's logging is set up.
Changes
Test plan