Chris,

I think maybe Mark answered a similar question a while back indicating the
only supported method within the Servlet API was custom session tracking. I
could be remembering incorrectly. That's what we do however, because
without "snooping" into the Tomcat internals, I don't think there was a way
that we found.

Robert



On Tue, Feb 27, 2024 at 3:10 PM Olaf Kock <tom...@olafkock.de> wrote:

> Hi Chris
>
> On 27.02.24 15:19, Christopher Schultz wrote:
> > All,
> >
> > I'm looking at building some administrative tools into my application,
> > and I'd like to be able to inspect user sessions for certain attributes.
> >
> > I know that I can use JMX to make calls to the (session) Manager, but
> > it looks like the only things really exposed are:
> >
> > String[] listSessionIds()
> > String getSessionAttribute(String sessionId, String attributeName)
> >
> > There are other operations available but they aren't related to what
> > I'd like to do: get a reference to the Session object itself, so I can
> > get attributes as their *actual* types and not converted to a String.
> >
> > Is that possible using existing Tomcat-provided tools?
> >
> > Another option would be to register an HttpSessionListener /
> > HttpSessionActivationListener and keep track of all the events so I
> > have my own "private" set of references to all of those sessions.
> >
> > Is there a way to do this without writing my own session-tracking
> > code? The old HttpSessionContext interface has been deprecated for
> > ages and implementations are required to be no-ops.
> >
> I can't really provide a recipe, but have a question for clarification:
>
> As you mention JMX, it sounds like you want to access the session from
> out-of-application context? If that is the case, you might have a hard
> time getting any session objects, if their classes are private to the
> web application's classloader. Strings naturally will work, but for
> others you'd need severe class loading or reflection magic to make sense
> of them.
>
> HttpSessionListener sounds more "in context", and more doable.
>
> I'm not aware of a way that does not involve custom session tracking
> code. But that doesn't mean anything: I can easily be proven wrong :)
>
> Olaf
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to