Sorry for top-posting. It's the default with my mail program

On 7/20/2019 11:27 AM, Konstantin Kolinko wrote:
> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods <>:
>> OK. That was really weird.
>> As I said in my message, following the directions on the web did NOT
>> work. It didn't force redirection from http to https.
>> What it DID end up doing was to kill the tomcat servlet application.
>> Before the change it was working fine, and after the change it would
>> only generate a 404 page.
>> I reverted to the original /conf/web.xml, restarted tomcat and the
>> servlet application is back up and running perfectly.
>> So this code in /conf/web.xml affected the servlet but not the ROOT
>> static web pages.
> 1. The web.xml file and its behavior are defined in the Servlet Specification.
> Some random instructions on the net have to be used carefully.
> 2. The web.xml file is the one in your web application (WEB-INF/web.xml).
> The /conf/web.xml file provides defaults for all web applications, and
> SHOULD not be edited. (The /conf/context.xml should not be exited as
> well. That is another frequent error.).
> Those defaults are merged with the web.xml file of your web
> application using merging rules defined in the Servlet Specification.
> There is an option, "logEffectiveWebXml" [1] that turns on logging of
> the merged web.xml file.
I still am having trouble understanding why the web application's
WEB-INF/web.xml would be the appropriate place to put the change when I
want to affect ROOT. I would have thought webapps/ROOT/WEB-INF/web.xml
would have been the correct one.
> 3. Beware of typos.
> The tag "</web-recource-collection>" is misspelled.



And I checked that code several times before implementing it. Of course
it wouldn't work 'as designed'. Ouch.

I can clearly see why 'fixing stuff' using that code would generate the
404 errors I was seeing. That does prove I was editing the correct
web.xml files, at least. Since the typo was in the block that then
defined the url-pattern, messing that up would mess up everything.

One person asked what the logs said. Nothing. Start up log was normal,
access log was normal.

> There is an option, "xmlValidation" [1] that turns on automatic
> validation of web.xml against the XML schema specified in that file.
> (Personally, I usually run with
> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
> and that turns "xmlValidation" on as well).
> 4. Top-posting is bad.

Again, sorry. In the end I solved it using a Rewritevalve instead of
web.xml, and I think that may be the more elegant solution. Certainly
it's cleaner - edit server.xml and add one file, rewrite.config. That
takes care of everywhere; both the static pages I started wanting to
fix, and also the servlet application which I discovered could be forced
to run http when I was testing. This fixes all.

One last point. I started this particular application for a client back
in early 2001. At that time I was considered a maverick for choosing
open source (Tomcat, MySQL) over the then-ubiquitous proprietary
solutions "everyone" was using. I even got to speak at Unix user groups
at the time, and even spoke at a CIPS meeting in August 2001 (Montreal,
PQ, Canada) on the use of open source for enterprise solutions.

Mostly folks simply didn't want to believe it could be done.

Fast forward to 2019, when Tomcat & Mysql/MariaDB are now often the
ubiquitous choices, with proprietary solutions are used mostly where
upper management has bought the FUD.

A lot has changed in Tomcat in that time; in Unix as well. I started
with Solaris 8, then Solaris 10, and more recently Ubuntu. I love the
way things have gotten better.

More than that, I try to "keep up" with changes in security and overall
robustness and best practices. I did just update from Tomcat 8.5.41 to
9.0.22 on Wednesday. It went without a hitch and took about 30 minutes
total, including testing on the devel server. Basically it was easy
because I try and keep things up to date.

But... there are still places where legacy code lives in the
application. Sadly, I'm one developer and it was a pretty big system. I
tend to be proactive, but only if I think the benefit can really justify
the time spent figuring it all out.



> [1]
> Best regards,
> Konstantin Kolinko

This email has been checked for viruses by Avast antivirus software.

This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to