Mark,
On 1/14/22 02:51, Mark Thomas wrote:
On 13/01/2022 21:31, Christopher Schultz wrote:
All,
Does anyone know if it's possible and/or convenient to fetch the
jvmRoute from a servlet filter?
I'd like to write a Filter that puts some information like this into
the response headers:
X-App-Server-IP: 10.0.0.1
X-App-Server-Route: jvmRoute
Is it possible to get that information from only the request/context
information?
I assume you want the configured jvmRoute for the Engine.
Yup.
If the jvmRoute has been configured via system property (see
StandardEngine) you could read it the same way.
It's not in my case -- though it could be -- but I was hoping to build a
Filter that could be used by anyone without any environmental restrictions.
Other than that you'd have to get it via Tomcat internals.
Okay. Looking at the JMX tree, where I only have a single >Service> and
<Engine> defined (which of course is very common), it looks like I can
just request /[Service]/Engine with no further adornment.
But I'm not sure how to get the "[Service]" name. I can cast
HTtpServletRequest to o.a.c.connector.Request and from there I can get
the o.a.coyote.Request but neither of those seem to have access to the
engine, service, etc. I could make it a configurable setting of the
Filter, with "Catalina" being the default. Is there any other way to get
the service name from within a running Tomcat?
At this point, if I have to manually-configure the Filter it may make
more sense to just use/write some simple Filter that allows you to set
*any* header like url-rewrite or a simple "set all these headers" Filter.
Any suggestions? I'm trying to investigate an issue with a client where
the web application's behavior does not make any sense[1]. It looks much
more like the browser, proxy, or load-balancer is caching a GET request
instead of NOT caching it, like all the response headers require of
those proxies. Probably not the browser, as the response takes non-zero
time and it doesn't say "served from the cache". Tracing the route
through the lb->httpd->tomcat seemed like a good next-step. For now, I'm
just adding request.getLocalAddr to the response headers.
-chris
[1] Save -> redirect -> load appears to skip the "save" part. Forcing
the page to reload /sometimes/ causes the save to occur. Like I said, it
makes no sense,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
