ansaurus

Question

Answer 1

A:

When we migrated to Tomcat 6.0 we had some problems with our application as it was shipped with the standard EE libraries, the ones that declare javax.servlet and similar stuff - I can't recall the specific name now. It worked fine in Tomcat 5.5 but did not work in Tomcat 6.0. We had some theories why it didn't work:

Tomcat 5.5 would simply ignore these libraries in the class loader and Tomcat 6.0 would not;
These libraries were compatible with the EE specification for Tomcat 5.5 but not for 6.0.

This project was a Maven build. We tracked the dependencies, excluded whoever included those libraries, and added the correct libraries to the version of tomcat that we were using, but as "provided", which means that they are not shipped when the application is packaged. Then it worked.

Other than that, I don't recall any problems. But this one was tricky to find. I will not migrate to Tomcat 6.0 while they're providing support for Tomcat 5.5.

Ravi Wallau 2009-11-19 23:07:48

My application does not include any jars which include javax.* or java.*.

dacracot 2009-11-19 23:24:39

It is at any way a bad practice to include appserver specific libraries in webapplication. Just because of those kind of unportability problems.

BalusC 2009-11-19 23:47:40

@BalusC It came from some other dependency that we were adding. When we noticed this problem we reviewed our dependencies to make sure that nothing unwanted was being carried.

Ravi Wallau 2009-11-20 03:22:03

Answer 2

+1 A:

The Apache Tomcat website has a Migration Guide that you might want to check. You may find some usefull information in it as you know what your application uses better than SO readers do :)

Matt Raible reports some more feedback in this post:

he was able to copy XML files without any problems (over conf/server.xml and conf/Catalina/**),
he had to include commons-logging.jar in some webapp as it has been packaged renamed,
he had to remove el-api.jar for JSF.

Regarding the specific changes you made, I guess you'll have to apply them again. But I'm not sure they'll need adjustment.

But actually, I'm wondering why you migrate your mature application. Do you plan to use Servlet 2.5 and JSP 2.1 APIs? Are you interested by the other improvements?

Pascal Thivent 2009-11-19 23:28:08

I looked at the "Migration Guide"... and to be honest... its lame. Only 270 words and nothing said.

dacracot 2009-11-19 23:54:45

Oh, and the reason to migrate... We are considering using Liferay which is dependent upon 6.0.x apparently, and we don't want to maintain two versions of Tomcat.

dacracot 2009-11-19 23:59:01

Answer 3

+1 A:

Upgrading Tomcat 5.5 to 6 is no big deal. Basically you just need to reconfigure the stuff in /conf as it was.

One important detail is that Tomcat 6 has all the default libraries in one /lib folder while Tomcat 5.x has them spread over /lib, /shared and /common and its subfolders. Verify if there aren't extra non-appserver-specific JAR files dropped which might need to be copied to Tomcat 6. Often those are only be the JDBC drivers and other JAR's which are required by the container managed datasources and other resources. Further on, Tomcat 6's /conf/catalina.properties also has new properties shared.loader and common.loader wherein you can specify those kind of paths yourself. Useful to externalize webapp properties files, xslt files, i18n files and so on.

Migrating webapplications to another server is another story. The biggest problems would arise in the classpath. It may happen that the developer has somehow dropped some appserver-specific JAR files in the /WEB-INF/lib. That would cause "unexplainable" ClassNotFoundException or NoClassDefFoundError problems whenever the webapp is deployed on an appserver of a different make/version. But if the webapp is all "clean", then I don't forsee real problems.

BalusC 2009-11-20 01:58:31

I am having the problem you describe, the "unexplainable" ClassNotFoundException. My /WEB-INF/lib consists of orai18n.jar, saxon9.jar, and my own tox.jar. Honestly can't remember why orai18n is there. Perhaps this is a starting point.Also, what do you mean by a "clean" webapp?

dacracot 2009-11-20 16:18:02

First, what's the name of the missing class? If it is one of the Java EE classes which ought to be default supplied by the appserver, then it means that the `WEB-INF/lib` is dirty (see 3rd paragraph). If it concerns another class which is not by default supplied by the appserver then verify if there aren't any JAR's in Tomcat 5.5's library paths which should be copied to Tomcat 6 (see 2nd paragraph).

BalusC 2009-11-20 16:27:13

It is the former... the logging mechanism which should be part of tomcat is being reported as missing. But I'm still not clear as to what you mean by "dirty". I've only three jars in my app's WEB-INF/lib. My jar is "clean". I certainly trust the saxon9.jar. Perhaps the oracle orai18n.jar is the issue?

dacracot 2009-11-20 16:33:52

With "dirty" I mean that the `WEB-INF/lib` contains appserver-specific JAR's which doesn't belong in there. This is likely not the root cause of your problem. Can you please post the entire exception and the stacktrace? Edit it in your topicstart if it gets long.

BalusC 2009-11-20 16:37:16

Posted the exception.

dacracot 2009-11-20 16:45:33

That's part of the commons logging which has been package renamed as pointed out by Pascal Thivent in his reply. You can download it here: http://commons.apache.org/downloads/download_logging.cgi

BalusC 2009-11-20 16:51:11

ansaurus

tags:

views:

answers:

Migrating from Tomcat 5.5.x to 6.0.x.

related questions