Well, the exception looks like, as if somebody has tried to change the
name of the user-realm from
/srv/www/tomcat5/base/conf/tomcat-users.xml to
/srv/www/tomcat5/base/conf/tomcat-users.xml.new .
AFAIK Tomcat will never ever change configuration-files, except
creating new context-definitions when deploying an application
containing one in META-IF.
The next sentence is just a shot from the hip, and maybe I'm wrong,
but it might be worth a try if you're out of any other ideas:
Looking back, I recall that Suse is very special with the installation
of some programs - meaning, sometimes Suse duplicates
configuration-files on places where you'd never expect them. Worse,
when you change a configuration-file in their original location, Suse
sometimes just doesn't care and copies the old copy over new new
version.
I guess that you've installed Tomcat from the Suse repositories using
something like Yast, right?
Just to be on the fase side, try the following (as root):
find / -type f -name server.xml -print
Maybe Suse keeps a copy in some hidden place and is using this one.
To me, according to your description above, it looks pretty much as if
the server.xml is not read by Tomcat but another file.
Btw., what gives "echo ${CATALINA_HOME} ${CATALINA_BASE}" ?
On your box, do you have a directory "/usr/share/tomcat" containing
something like "config"?
Maybe one hint for the future:
It's strongly recommended using a vanilla installation of Tomcat, and
not the one fro the OS-repositories: It's easier to maintain when
sticking to the documentation, it's easier to apply updates, you'll
get updates faster and so on..
HTH
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
