- Core:
- Full documentation:
- Deployer:
-
Extras:
- JMX Remote jar (pgp, md5)
- Web services jar (pgp, md5)
- JULI adapters jar (pgp, md5)
- JULI log4j jar (pgp, md5)
Send us your questions on how to improve, troubleshoot or manage your Apache Tomcat deployment. Our team of Apache Tomcat committers and community leaders will review all submitted questions, and post the most relevant questions along with an answer from a real Tomcat Expert. The questions and answers will be made public for the community to collectively learn from and discuss.
Questions submitted are not guaranteed to be posted. The selection process will favor questions of the day that are the most interesting, timely, or relevant to our community. Ensuring your questions is concise, well written, and without annoying broken links, bad grammar or spelling errors will help your question to be answered more readily by the Community Moderators.
I installed apache tomcat 6 on my server and created my first index page in the ROOT folder and everything worked perfectly. But as soon as I started to attempt to tweek the page to make it look how I wanted it to I noticed that the changes where not being reflected in the borwser and the old page continues to be displayed. Does anyone know why it does this and how it can be fixed so I can see changes immediately?
There are a number of settings which may apply to your situation.
If the file you are editing is a small 'static' file, Tomcat may be caching it in memory. The attribute values of the Context element which govern this are: cacheMaxSize, cacheObjectMaxSize, cacheTTL and cachingAllowed.
You can find more details about their values in the Tomcat Documentation at: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
If the resource you are editing is a JSP file, then you should check to see if the attributes of org.apache.jasper.servlet.JspServlet in apache-tomcat-6.x/conf/web.xml have been adjusted - it's usual to disable attributes associated with file recompilation during development, before placing the server into production.
Each attribute is well documented in the configuration file, it's worth reading the whole of the standard web.xml to understand more about how Tomcat works.
In section 2.1 of "Tomcat: The Definitive Guide" 2nd edition, the authors write, "...we have not heard even a single reported incident where a machine's security was compromised because Tomcat was running as root."
Does anybody know if that claim still stands?
I am not aware of a case, but that doesn't mean it hasn't happened.
Running as root is discouraged because an attacker who manages to compromise a server will then have substantially increased ability to further attack the system.
The nature of the question indicates that a Unix-like system is in use, which also means that iptables or ipfw are likely to be available - making it possible, trivial even, to run Tomcat on a port higher than 1024 under a dedicated user.
Using iptables:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 127.0.0.1:8080
or ipfw (BSD / OS X):
ipfw add 100 fwd 127.0.0.1,8080 tcp from any to any 80 in
The jsvc (called tomcat-native in Tomcat 7.0) unix daemon is shipped with each release, starts as root, but runs Tomcat under a specified user, also making it simple to place a service control script in /etc/init.d/.
Security and hardening aren't just a matter of protecting a single server - one compromised server inside a network can easily lead to more machines being attacked and compromised both inside an enterprise and outside.
When it's this easy to run Tomcat with it's own user account, there's really no reason not to.
How do i run silverlight(xap file) app on apache tomcat?
A Silverlight XAP file is just a ZIP formatted archive of the Silverlight application - which being a client side technology doesn't need much in the way of server support.
You'll need to add the mime-type for .xap, which is "application/x-silverlight-
<mime-mapping>
<extension>xap</extension>
<mime-type>application/x-
</mime-mapping>
I'm using Tomcat 6 and am having trouble getting large pages to load. We've developed a page for a site that gets generated for specific cities. When I test it on my IDE, it works without a hitch. However, when I deploy the app to our server running tomcat 6, on locations with a small amount of information seem to work. I've isolated that it related to the size of what is being generated. Is there a way to increase the size of the files that tomcat will generate from jsps?
There is a restriction on the size of a compiled method, which is 64kb of bytecode - but this must not be confused with the size of the data output from a method.
I'd expect it to be a low probability that you've run into this restriction, but if you have then it shouldn't be too hard to refactor the JSP to get around it.
From the limited information you provide it's nearly impossible to tell what the likely source of the problem is. I'd be looking for Exceptions in the Tomcat logs and examining whether the page was failing because it depended on other resources which are unable to deliver large amounts of information in a timely fashion.
If the problem is reproducible then it should be relatively easy to narrow down the portion of the code which causes the problem; even if this means selectively commenting out section of the JSP and testing each part of it separately.
You have a few problems, the cause of them is not entirely clear.
One thing to bear in mind is this: when you're using Apache HTTPD in front of Tomcat, if you can get it working under normal HTTP then configuring HTTPS should be simple.
HTTP and HTTPS in Apache HTTPD are treated as separate VirtualHosts, so it should just be a case of ensuring that whatever configuration you've applied to the HTTP virtual host is also applied to the HTTPS host.
This can be achieved with ease, by placing all of the mod_jk or mod_proxy (in your case) configuration in an external file and using the 'include' mechanism.
The HTTP address you provide is using the port 8080, which Tomcat specifies as the default port for it's own HTTP connector - suggesting that you're not connecting via Apache HTTPD when you make that request.
The ProxyPass statements point both /abc and / to the same path, which is a subpath of the application /abc - this seems unusual. I'd expect to see the path http://server:8080/abc, without the '/implement' extension, this may be the source of some of the missing images.
The last issue, regarding the message "line 56 Object expected" is likely to be a Javascript problem, possibly caused by a script file experiencing the same 404 as the images.
In order to debug the problem, it would be better to start with a fresh configuration - discard whatever you have so far, or copy it to a backup.
The Fiddler or ieHttpHeader plugins for Internet Explorer will make it easier to examine which resources are, or are not being served correctly.
You will need to examine both the Apache HTTPD and Tomcat access logs to see which server is serving each request and check that the result is the expected one.
Configure the HTTP instance and test it thoroughly before attempting the HTTPS configuration.
Hi, I have Tomcat 5.0.28 running on more than one client with a SSL connector that allows identification with spanish certificates FNMT, DNIe and Camerfirma (among others).
The first thing to note is that you are currently running an unsupported version of Tomcat, which in Apache terms means that it's extremely unlikely to get any more upgrades or patches. It's in beta now, but a stable release of Tomcat 7.0 is likely to happen towards the end of this year, which will put you a full 3 versions behind the current release.
A detailed answer to the question requires more information, such as the exact versions of the server operating system, the JVM type and version, how you've configured the SSL connector and whether you're using APR or not.
This type of problem most often appears when a client has unexpectedly terminated the request, or disconnected before the request has completed, implying that the source is at the client end of the connection - it's often an unintended consequence of a user deciding to view a different page before a previous request has finished.
In your case, you state that some clients are not having the same problem; in order to track down the source you should monitor the access, error and application logs and match individual requests to the log entries. Look for commonalities between source IP address, User-agent and try to get exact details of the environment of the client which has identified the problem. If there is definitely only one client experiencing the problem, then you'll need to determine what's different about their configuration. It's possible that there's nothing wrong with your application, but that a server or network misconfiguration is the cause of the fault.
Even recent releases of the Sun JDK/JRE don't have all of the Certificate Authorities in use currently, which is another possibility for the cause - though I wouldn't expect to see a connection reset event as a symptom - but still, check the client isn't using a certificate from a new CA.
I can't guarantee it would make any difference, but I'd strongly recommend putting a testing and deployment plan together to bring your environment up to reasonably current versions, particularly as there are vulnerabilities in SSL which are likely to unpatched in the setup you describe. Tomcat 5.5 should be the minimum version you're running on, if upgrading the JVM to a recent version is a problem.
How many "simultaneous users" can a Tomcat server support and where do I find this setting? I've read on the internet that Tomcat is limited to 15 "simultaneous users" and that Tomcat supports "unlimited numbers" of users. What's the real story?
Tomcat doesn't have such a setting and you shouldn't trust everything you read on the internet!
A limitation like 15 simultaneous users would make the large scale, high availability Tomcat deployments that are already powering banks, government applications and large corporations completely impossible. On the Apache Tomcat Users mailing list, for example, we see people fairly frequently who are debugging their applications under load tests simulating thousands of concurrent users.
One of the advantages of using software like Tomcat is that it provides the Servlet Spec environment, (which is usually enough to support most applications with a few Apache Commons libraries or the use of frameworks like Struts and Spring), but it's lightweight and uses comparatively little in the way of system resources itself.
The amount of concurrent users will depend on the server hardware (processors, memory), the types of resources being used within the application and what your application is actually doing. A fictional application which generates PDF reports on demand from large amounts of data, taking minutes for each request is going to need substantially more server resources to support a similar number of users to an application which is serving largely static or cached resources.
In Tomcat versions 6.0 and up, the best way to configure the number of threads the Connector uses is via the Executor element. http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html
The default setting for the maxThreads attribute is 200, which should be enough to get most applications started. In fact, in my experience you'll need to add more servers to scale up because of application memory usage before the maxThreads attribute gets too high.
So, to answer each question: Tomcat is not limited to 15 users; it will support however many concurrent users your application(s) can support.
How do you gracefully restart Tomcat? It will be good to have a standard way doing this. We created a health check url for the load balancer (e.g. /health). This url returns 200 status to indicate this service is up. There is a prob.txt under tomcat dir. If we delete this file, the health check will start returning 404. Thus, remove this box from load balancer. Wait for 2 to 3 mins before shutting it down the process to ensure all request have been processed.
Tomcat, unlike Apache HTTPD, does not have a graceful restart function, largely because of the consequences of it being an application server rather than a web server.
The restart time for server itself largely depends on how long it takes your application to start up, you should be able to start a fresh Tomcat instance in a few seconds - it's worth noting how long it takes to start up on your system, before you customise the configuration.
Instead of restarting the server, you can restart individual applications, which is nearer to the concept of a graceful restart and wouldn't incur the overhead of restarting all of the applications.
An appropriately secured* Manager application instance in each Host, will enable you to selectively restart an application. Automated requests can be sent to the /manager/text component using the same request structure as the /manager/html component, but with smaller output.
* The Manager application should be secured by adding the RemoteIpValve to it's Context definition, with only the specific IP addresses you'll administer the server from enabled.
I am a newbie in Tomcat.
In your about page you state as, "Apache Tomcat is the most popular java application server in the world." In other places I read it as servlet container, java http web server and so on.
We have a lot of different deffinitions, it is confusing.Can you describe it in more details, what TOMCAT exactly is? And can you describe internal components/archtecture of Tomcat and their interaction and general interaction with user.
Thanks!
In my consulting practice, I see alot of confusion about this question, and definitely not just from "newbies". Much of this is due to honest differences of opinion regarding "what's an app server", and some of it is due to differences in use cases and industry jargon. Also, there is the "marketing" component", where vested interests seek to position their product as an "app server" and their competitors (with virtually identical technologies) product as some thing less.
So, what's Tomcat? The reality is that it's many differnet things to many people, one of which is that's certainly the most widely deployed JAVA "Application Server". That said, it's NOT a direct competitor/replacement to the likes of WebLogic, WebSphere, etc, but for a huge percentage of the production JAVA applications in the world, Tomcat...perhaps augmented by one or more plug-in/add-on services...provides all the application infrastructure that's needed. Tomcat is:
Note: Tomcat should not be confused with the Apache web server, which is a C implementation of an HTTP web server; these two web servers are not bundled together.
It happens that this question is very timely, because I've been working on a blog series (first one should be out this week) about the trend to build (or migrate) applications onto Tomcat instead of the JEE Application Servers of the past. Those blogs will include much more detail and specifically discuss the questions regarding Tomcat vs JEE, what the differences are, etc. You can also get good whitepapers on the topic from some of the vendors who are basing hybrid products on Tomcat, such as SpringSource and MuleSoft. Finally, there are some excellent reference books that start with basic concepts and take you all the way thru the programming models and to configuration/deployment details. One of my favorites for beginners is "Tomcat: The Definitive Guide, by Jason Brittain and Ian F. Darwin and published by O'Reilly
So, Tomcat is indeed an "application server", based on many accepted definitions of app server. It is also a "servlet container". It is also a "web server". Tomcat is an excellent runtime environment for frameworks such as Spring, Groovy, etc, and it is also a core technology in many commercial products that layer application services and management tools around it to simplify integration and deployment.
Is Tomcat be made FIPS complaint ? Or changing the Crypto Provider to a FIPS complaint Provider enough ? Because When starting up it needs to invoke the self tests in FIPS mode , how can tomcat achieve this ? Is there a Tomcat Start up configuration file that can achieve this ?
Since this question usually is about FIPS 140-2 ("Security"), we'll assume that is the focus of this question.
FIPS is primarily focused on Encryption and targets the development and production processes, although FIPS 140 at higher levels also includes several other security areas. FIPS certification may not be necessary in all cases. It is sometimes sufficient to be able to run Tomcat with a FIPS compliant JSSE provider. It all depends on the FIPS Level and specific requirements of the procurement. At higher levels, and in many more sensitive projects, not only does the encryption have to be FIPS compliant, but so does much of the invoking application.
There are a couple of commercial Encryption options, including ones from SpringSource that have successfully tested Tomcat 4, 5 & 6 with a FIPS certified JSSE provider on 1.5 and 1.6 JVMs.
FIPS comes in hierarchical layers, each assuming the Level below is met. These are:
Additionally, FIPS 140-2 certification covers eleven software development and production areas:
I am not aware of anyone who has taken Tomcat through FIPS, which is an ongoing process, not an event. FIPS certification requires extensive documentation of development and test processes and must be (partially) re-done each time a new version of the software is released. At higher levels, third party (there are a VERY limited number of authorized certification agencies) auditing and certification becomes part of the process, adding additional cost and product delay.
As such, it's inherently quite costly (high hundreds of thousands of dollars to low millions each time), so it requires a very significant commitment in time and third party fees on the part of the software provider. It also dramatically slows new releases, since FIPS certification adds months to development schedules, so it's generally only appropriate for relatively static software.
.
Popular Links