Session listener added programmatically

[nicolasbron]

Hello,

With the new pax and jetty is there a way to add a session listener programmatically? With pax-web 7.x and jetty 9.4 I did something like:

public class OAuthFilter implements  Filter {

        @Override
	public void init(final FilterConfig filterConfig) {
               filterConfig.getServletContext().addListener(new SimpleHttpSessionListener());
        }

	@Override
	public void doFilter(final ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
                 ....
         }
}

But now such methods are throwing UnsupportedException.

[grgrzybek]

Yikes. Another bug as a feature.

According to jakarta.servlet.ServletContext#addListener(java.lang.Class<? extends java.util.EventListener>) JavaDoc, this methods throws exceptions:

• IllegalStateException – if this ServletContext has already been initialized
• UnsupportedOperationException – if this ServletContext was passed to the ServletContextListener.contextInitialized method of a ServletContextListener that was neither declared in web.xml or web-fragment.xml, nor annotated with jakarta.servlet.annotation.WebListener

So some exceptions may be thrown. But session listener should be safe to pass here...

May I see entire stack trace?

[nicolasbron]

I agree. That modifying filters, servlets should be forbidden. But the sessions should quiet safe and I don't see any risk in adding new. This is the stacktrace:

Oct 14, 2025 7:15:58 PM org.ops4j.pax.web.service.jetty.internal.PaxWebServletHandler initialize
SEVERE: addListener() is not supported.
java.lang.UnsupportedOperationException: addListener() is not supported.
	at org.ops4j.pax.web.service.spi.servlet.OsgiScopedServletContext.addListener(OsgiScopedServletContext.java:145)
	at com.oauth.filter.OAuthFilter.init(OAuthFilter.java:65)
	at org.ops4j.pax.web.service.spi.servlet.OsgiInitializedFilter.init(OsgiInitializedFilter.java:115)
	at org.eclipse.jetty.ee8.servlet.FilterHolder.initialize(FilterHolder.java:118)
	at org.eclipse.jetty.ee8.servlet.ServletHandler.lambda$initialize$2(ServletHandler.java:617)
	at org.eclipse.jetty.util.ExceptionUtil.call(ExceptionUtil.java:339)

I tried modifying the OsgiScopedServletContext and OsgiServletContext to simply pass it to the wrapping context but this didn't solve the problem. I no longer get the UnsupportedOperationException but the listener is not registered anyway. It looks as listeners are registered on org.eclipse.jetty.ee8.servlet.ServletContextHandler.startContext and it's run before the initialization of the filters. I will investigate it a little bit more tomorrow.

[nicolasbron]

Ok I found the culprit. In org.ops4j.pax.web.service.jetty.internal.PaxWebServletContextHandler you are overwriting method startContext. This method iterates over listeners and calls addEventListener for each (ordering them). And then it calls super method startContext. In this super method new listeners are added but never registered (called addEventListener). So I did a quick workaround by simply adding something like that (after super.startContext() call). This together with removing UnsupportedOperationExcepton from OsgiScopedServletContext & OsgiServletContext solves the issue. I can create an MR if you'd like.

		// this method will start the just added listeners in the order we wanted
		super.startContext();

        // if any listener was registered programmatically, we need to add it now
        for (int pos = rankedListeners.size(); pos < orderedListeners.size(); pos++) {
            EventListener el = orderedListeners.get(pos);
            super.addEventListener(el);
        }

[grgrzybek]

Thanks for digging this.
I'll check later (next week?) - you can try running the tests to check this change, because these listeners, scoped contexts and ranking is kind of fragile...

[grgrzybek]

Issue created: #2119