Chuck and Venkat,
On 7/25/24 22:48, Chuck Caldarale wrote:
On Jul 25, 2024, at 20:45, venkatd...@hotmail.com Shanthisowjanyadama9
<venkatd...@hotmail.com> wrote:
>>
I am also wondering why backward compatibility is not maintained
in Tomcat Server end when I switch from one version of Tomcat to
another version.
Compatibility is maintained, except when relevant standards are being
violated, especially when related to security. In some such cases,
the old, invalid behavior can be re-enabled with configuration tags.
Check the Tomcat 9.0 documentation to see if anything might be useful
in your case.
Most “compatibility” problems are actually application bugs, such as
hanging onto references to response or request objects after a
response has been committed.
+1
I have an application originally built for Tomcat 4.something that has
never had any compatibility issues between then and Tomcat 9.
I've even recently been deploying it on Tomcat 10.1 and allowing Tomcat
to "migrate" the entire application to Jakarta EE APIs and it runs
flawlessly.
Any apparent incompatibilities are likely to fall in one of several
categories:
1. Use of Servlet Spec features, etc. that have been deprecated
and should not be used. The fix here is to write standards-compliant
applications using the current specifications and the nuances
thereof. For example, some APIs are still present but should never
be used (e.g. SingleThreadServlet or whatever, or getRealPath).
2. Significant non-standard configuration, usually trying to work-around
some abuse of one or more specifications. If you are tweaking the
handling of URI characters, slash processing, etc. then it's time
to fix your application so that it doesn't rely on those risky
configurations.
3. Use of Tomcat-specific APIs, internals, or libraries. Just don't
do this. You don't want to be locked-in to any specific vendor, do
you? I avoid vendor lock-in, even if the "vendor" is ASF.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
