kjkoster
04-06-2010, 22:34
Dear All,
I hang out on #tomcat on freenode.net (http://freenode.net/) a lot, basically providing free customer support for Tomcat and other Java application servers. :-)
A lot of support questions I answer find their root in the fact that there are repackaged Tomcats out there. The problem with such packages is that they were designed to adhere to local standards. They are intended to be used by advanced users of Tomcat. Users that are comfortable with Java's security managers (http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html) and know how to troubleshoot exceptions. Unfortunately, these packages end up being used by people who are new to Tomcat and sometimes even new to Java. They end up in a deep hole because of the decisions that the package maintainers made. We on IRC cannot help you, because we have no idea how the package maintainers have laid out Tomcat for you.
So that is why my advise is: use a real Tomcat.
To install a real Tomcat, do the following: download the core zip from the official Apache Tomcat distribution site (http://tomcat.apache.org/). Unzip the zip. On UNIX, run "chmod 755 apache-tomcat*/bin/*.sh" to make the startup scripts executable. Run the startup script from Tomcat's bin folder.
That is all. You don't even have to uninstall the package, so you can use them side-by-side.
Still not convinced? Ok, let me make a short list of issues that you will have to tackle if you insist on using the packaged Tomcat.
Different File System Layout
Most repacked application servers try to follow the file placement conventions of their target platform. While commendable, it means that people who try to help you have to guess where everything is. When we say "edit ${tomcat}/conf/server.xml", you will have to translate that into whatever layout your package maintainers chose. We don't know where your package maintainer put server.xml or the context files. We cannot look on your disks.
Bad Default JVM Dependencies
Some distributions end up making Tomcat depend on gjc as its JVM. The idea behind gjc is nice and it is nice for many applications, but is just is not a complete JVM implementation. Tomcat depends on things that gjc does not provide. Use a Sun JVM instead.
Different Security Manager Settings
Java has excellent application sandboxing support. It allows you as an administrator to specify in great detail what a running JVM can and cannot do. This is what for example applet security is based on. For example, you can configure the security policy so that your JVM cannot make its own network connections, other than to a specific IP and port. Or you can forbid the JVM to write any file but its log files.
By default, Tomcat ships with the security manager disabled. That is good, because each application has different needs. Some repackaged Tomcats ship with not only the security manager enabled, but with serious restrictions for what the Tomcat can do. This leads to all sorts of problems, such as being unable to connect to databases and web services.
Different Logger Settings
Some packages configure Tomcat's loggers to suppress all output. This is immensely confusing for first-time users. They expect Tomcat to talk about the problems it sees. Tomcat will do that, but your package maintainers have chosen to destroy that information and keep you from knowing what, if anything, when wrong.
If after this you still insist on using a packaged Tomcat, and you run into a problem: get help from your package maintainer. On IRC, there is not much we can do for you. :-/
Kees Jan
I hang out on #tomcat on freenode.net (http://freenode.net/) a lot, basically providing free customer support for Tomcat and other Java application servers. :-)
A lot of support questions I answer find their root in the fact that there are repackaged Tomcats out there. The problem with such packages is that they were designed to adhere to local standards. They are intended to be used by advanced users of Tomcat. Users that are comfortable with Java's security managers (http://java.sun.com/javase/6/docs/api/java/lang/SecurityManager.html) and know how to troubleshoot exceptions. Unfortunately, these packages end up being used by people who are new to Tomcat and sometimes even new to Java. They end up in a deep hole because of the decisions that the package maintainers made. We on IRC cannot help you, because we have no idea how the package maintainers have laid out Tomcat for you.
So that is why my advise is: use a real Tomcat.
To install a real Tomcat, do the following: download the core zip from the official Apache Tomcat distribution site (http://tomcat.apache.org/). Unzip the zip. On UNIX, run "chmod 755 apache-tomcat*/bin/*.sh" to make the startup scripts executable. Run the startup script from Tomcat's bin folder.
That is all. You don't even have to uninstall the package, so you can use them side-by-side.
Still not convinced? Ok, let me make a short list of issues that you will have to tackle if you insist on using the packaged Tomcat.
Different File System Layout
Most repacked application servers try to follow the file placement conventions of their target platform. While commendable, it means that people who try to help you have to guess where everything is. When we say "edit ${tomcat}/conf/server.xml", you will have to translate that into whatever layout your package maintainers chose. We don't know where your package maintainer put server.xml or the context files. We cannot look on your disks.
Bad Default JVM Dependencies
Some distributions end up making Tomcat depend on gjc as its JVM. The idea behind gjc is nice and it is nice for many applications, but is just is not a complete JVM implementation. Tomcat depends on things that gjc does not provide. Use a Sun JVM instead.
Different Security Manager Settings
Java has excellent application sandboxing support. It allows you as an administrator to specify in great detail what a running JVM can and cannot do. This is what for example applet security is based on. For example, you can configure the security policy so that your JVM cannot make its own network connections, other than to a specific IP and port. Or you can forbid the JVM to write any file but its log files.
By default, Tomcat ships with the security manager disabled. That is good, because each application has different needs. Some repackaged Tomcats ship with not only the security manager enabled, but with serious restrictions for what the Tomcat can do. This leads to all sorts of problems, such as being unable to connect to databases and web services.
Different Logger Settings
Some packages configure Tomcat's loggers to suppress all output. This is immensely confusing for first-time users. They expect Tomcat to talk about the problems it sees. Tomcat will do that, but your package maintainers have chosen to destroy that information and keep you from knowing what, if anything, when wrong.
If after this you still insist on using a packaged Tomcat, and you run into a problem: get help from your package maintainer. On IRC, there is not much we can do for you. :-/
Kees Jan