On 10/22/2012 1:16 PM, geoff.culli...@bell.ca wrote:
Hi:
I have inherited a set of Tomcat 5.5.23 webapps on an aging linux
server and can now upgrade to a brand new server. My plan would be to
acquire a new server running a current linux version, upgrade to
Tomcat 7.0.32, completely clone the apps, then cut over the new apps
. I have been searching for docs to help clone, edit and redeploy
the webapps on the new server with little luck. Is there someplace I
can look to overview the process to follow?
Thanks and best regards,
Geoff Culliton geoff.culli...@bell.ca
In short, probably not since you are moving up two versions (good btw).
Start with:
http://tomcat.apache.org/migration-6.html
http://tomcat.apache.org/migration-7.html
Things that may trip you up are (in no special order).
1. Directory structure change (5.5.x -> 6.0.x)
This governs where you put JDBC libraries and extra endorsed libraries
among other things.
2. Logging changes (5.5.x -> 6.0.x -> 7.0.x)
Particularly if you rely on standard out logging (move your applications
to a logging framework) you may be in for some surprises.
3. Manager role changes (5.5.x -> 6.0.x -> 7.0.x)
The manager URLs, roles, and accounts have changed in 7.0.x. The second
link above details the changes.
4. Jar scanning
This occurs due to compliance with the Servlet 3.0 specification. You
may improve start up time and memory (although 7.0.32 does a great job)
by including jars to skip in catalina.properties.
Read this for more information:
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html
Also, look at the current $CATAINA_BASE/conf/catalina.properties file
shipped with Tomcat.
If you have standards-compliant web applications then there should not
be too many challenges.
Watch out for things like:
1. quoting (quotes within quotes)
Use "text 'other text' " instead of "text "other text" "
2. wildcard imports on JSP pages
This is mentioned on the second migration page. Wildcard imports could
reference classes that are newly a part of the Servlet 3.0
specification. Use specific imports in order to solve any name collision
problem.
3. invoker servlet
It's been discouraged for a long time, and disabled by default in 5.5.x
and 6.0.x. It's completely gone in 7.0.x. It's time to explicitly map
the servlets in web.xml or move to the Servlet 3.0 specification and use
annotations.
My generic thoughts on this are:
1. Install a new version of Linux
2. Install the latest version of the JRE from Oracle
Manage this manually (I use links and environment variables). I've never
had good luck with using the alternates framework, although your mileage
may vary.
3. Create an unprivileged account for running Tomcat
4. Install a copy of the latest Tomcat downloaded from Apache
Manage this manually, including writing your own init scripts. While you
can wade through the repackaging structure that most Linux distributions
impose, I've always found it easier to manage all of this myself.
Use the default Tomcat settings for testing. Tweak them once you get
everything running.
5. Drop in a representative WAR file and test
Run JMeter or Selenium tests and see what breaks. Take notes, fix the
issues, and then make appropriate changes to other applications.
Again, if you have standards-compliant web applications there should not
be many (if any) issues.
. . . . just my two cents
/mde/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
