On Fri, Mar 22, 2024 at 9:28 AM Christopher Schultz < ch...@christopherschultz.net> wrote:
> Robert, > > On 3/21/24 15:31, Robert Turner wrote: > > We receive the sessionWillPassivate and sessionDidActivate callbacks > > on startup. Odd that you are not. That's how we achieve the same. > On 3/21/24 16:21, Robert Turner wrote: > > Just to add a bit more information, our handler class, for better or for > > worse, implements the following interfaces all in one class: > > > > implements HttpSessionBindingListener, HttpSessionActivationListener, > > HttpSessionIdListener, HttpSessionListener, ServletContextListener > > Hmm. > > I'm already using HttpSessionListener and HttpSessionActivationListener > and logging every event I receive. > > HttpSessionIdListener only lets you know when ids are changed, and I > actually don't care about those events. I added it, and see no change in > behavior. > > HttpSessionBindingListener shouldn't do anything, here, as it will only > be called when objects are added or removed (and it only *that object*). > During activation and passivation, I wouldn't expect anything to be > added or removed. > > ServletContextListener wouldn't do anything in and of itself, except > possibly get the listener started earlier. I added it and do not see any > change in behavior. > > Yeah, I wasn't really suggesting adding all those listener interfaces -- more just saying that's what we did in case somehow it made a difference for you. Certainly you shouldn't have to add them to get it to work. > > We also use that same class as our "session model" object that we bind as > > an attribute to the session itself (it's a bit of a mixed bag > historically > > that I want to clean up). > > > > And in terms of registration, we do not have any annotations on the > class, > > instead we register it in web.xml (in the application WAR file) using a > > standard listener entry: > > > > <listener> > > <listener-class><<class name>></listener-class> > > </listener> > > > > Our web.xml is set at Servlet API version 3.0 (kind-of old), and we are > > running against Tomcat 9.5 (and this worked on 8.5 and before as well). > > > > Not sure if that adds anything Chris that you haven't already looked at. > > I believe mine is set up identically to yours at this point, except for > the HttpSessionBindingListener. > > > I would really prefer a way to query the sessions from the app, but as we > > know, that's not part of the current Servlet specification, or any > > extensions Tomcat currently provides. > > It wouldn't really be appropriate for Tomcat to provide any "extensions" > like this because it would make applications reliant on capabilities > that aren't standard. When companies do that, it's called "vendor > lock-in" and it's not a good look for ASF. > > Yeah, vendor lock-in isn't great -- and I wouldn't really suggest Tomcat doing that either; it would be better in the Servlet specification, but I doubt, for various reasons, it would get added. Your case is certainly odd -- I suppose you might have to resort to firing up a debugger and debug build and seeing what's going on in Tomcat...(at least you are more used to doing that on Tomcat than most of us). > >
