James,
On 10/16/25 1:58 PM, James H. H. Lampert wrote:
In response to
Either I'm stopping and restarting the wrong bean, or stopping and
restarting the bean doesn't reload the context.xml.
I'll try other beans, but if anybody can suggest a different bean to
try, please do.
On 10/16/25 10:08 AM, Christopher Schultz wrote:
Exactly which file did you change?
Dear Mr. Schultz:
The object here is to be able to have the manager context unreachable
from the outside by default, but make it reachable as needed, without
having to restart Tomcat in order to do it. (Running manager from the
box itself is not possible, because it's an IBM Midrange box.)
So what you are saying is that you don't have the opportunity to do
anything like $ curl http://localhost/manager/..... right?
AutoDeploy is set to false in conf/server.xml, because otherwise, WAR
files get re-expanded, overwriting any instances of our webapp that have
had internal parameters set in their own web.xml files.
Tomcat shouldn't overwrite file deployed web applications unless the WAR
file has changed since it was originally expanded. If you get an
overwrite on every start, I'd be interested in determining why that's
the case.
It's a longer process, but I might point you in the direction of a few
possibilities for using local resources with a non-changing web.xml
file. It may save you a bunch of headaches.
The servlet spec allows you to define <context-param>s in
META-INF/web.xml. These can be overridden by <Parameter> elements in
your META-INF/context.xml file, which can either be bundled in with your
web application or overridden locally with a file in
CATALINA_BASE/conf/[engine]/[host]/[app].xml. This may give you some
flexibility in how you set local context-params.
If you are using some other kinds of configuration, might I suggest that
you change the application to first look for a locally-deployed set of
e.g. properties and then fall-back to a file bundled with the application?
Ideally, you shouldn't have to modify your web application to deploy in
in different environments.
So I tried stopping manager (from a jmxterm session running on the same
box), changing the RemoteAddrValve in the manager context's META-INF/
context.xml file, and then starting manager back up. No joy. The change
had no effect whatsoever, whether I changed the allow clause, or I
commented/uncommented the filter.
Right: I'm trying to find out exactly which file you changed. I know
nothing about jmxterm, but I very much doubt it persists anything to a
file. If you use jmxterm to change the RemoteAddrValve's IP address
range, you will change the configuration in memory but not on the disk.
Restarting the Manager at this point will lose this configuration and go
back to the on-disk settings.
Why not just set the IP address to something that will work? It doesn't
have to be 127.0.0.1. It could be "any 10.*" or similar that will be
available from the "outside".
I also tried starting Tomcat with the manager context physically absent,
then moving it in while Tomcat was running, but JMX couldn't find the
beans for it.
If you have autoDeploy=false, then you can't deploy a web application by
dropping a WAR file into webapps/ ... that's what auto-deploy is. If you
want to deploy after startup with autoDeploy=false then you will need to
use JMX to deploy a WAR file from elsewhere on the disk. It's awkward,
but doable. This may be your best bet if you want to temporarily enable
the Manager application. But I have to wonder if you have an X-Y
problem, here.
Why do you have to change the RemoteAddrValve allow or deny list?
Why do you have to conditionally deploy the manager?
Why do you have to deploy the manager at all?
Ditto if I tried hiding manager with an ignoreDeploy clause on the
host tag in conf/server.xml.deployIgnore? That will have the same effect.
If the application isn't deployed, then you cannot remote-control it via
JMX.
So far, the only thing I've found that works is renaming manager to
something that would be difficult to guess, which is merely "security by
obscurity" (then again, so are passwords, PINs, and combination locks).
Security by obscurity is okay, as long as it's not the /only/ control
in-place. If you have the Manager called "not-manager" but it doesn't
require any kind of authentication, then you aren't really all that
secure. But if you have authentication enabled and you also re-name it,
then it's fine. You just get different kinds of errors in your log when
someone tries to probe your service for the manager application.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
