Working software is the primary measure of progress for software development teams. This is one of the principles of the Agile Manifesto and has led agile software teams to focus on implementing the most important features of a system early and efficiently. These teams usually provide frequent deployments of the software in order to receive feature validation from the business and to show project progress. The benefits are quick and frequent feedback for the developers and congruous applications for the business.
The practice of automated continuous deployment ensures that the latest checked in code is deployed, running, and accessible to various roles within an organization. Project managers can have a place to check on project progress, testers have a view into the latest builds, developers can see the their modules working with the modules from other team members, and stakeholders can see how their requirements have been translated into working software. Tomcat and tc server easily integrate with continuous integration servers to allow agile teams to realize continuous deployment while utilizing a lean application server (another practice of agile teams). You can start practicing continuous deployment very quickly using Tomcat or tc server, Jenkins, and your source control system of choice.
The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.26
This release is primarily a bug fix release and includes numerous bug fixes compared to version 7.0.25. The notable bug fixes include:
@HandlesTypesprocessing which no longer loads all classes on web application start.
Please refer to the change log for the complete list of changes:
Note that this version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures.
I am interested in catalina.out log file rotation, I have an application where logging to catalina.out is very huge, say 0.5 MB / sec.
So I have written one script to handle this which is shown below.
# crontab -l | grep catalina
0,30 * * * * bash /catalina_log_handler.sh >/dev/null 2>&1
# more /catalina_log_handler.sh
The catalina.out file is created by a shell redirection, ex ">> catalina.out 2>&1". This catches anything written to System.out and System.err and places it into the catalina.out file.
Given this, a good way to rotate catalina.out is to alter the script to pipe the output to a log rotation script rather than directly to a file. This will allow you to rotate the logs without restarting Tomcat and without copying the entire contents of the log to another file.
It's a pretty simple change to catalina.sh and it is described at this link.
I'm trying to setup BASIC auth on my tomcat 7 which is listening on port 80 and 443.
I have made the following changes:
In the web.xml of the web-app
Your configuration looks OK to me. I copied and pasted it into my local Tomcat 7.0.25 installation and it worked OK for both HTTP and HTTPS traffic.
One possible issue, which is very easy to test, is that your browser has your authentication credentials cached. With BASIC auth, your browser will only prompt you for credentials the first time you authenticate to your site. After a successful authentication, it will not prompt you again. To force your browser to prompt you again, you'll need to completely close out the browser.
An alternative, and my personal preference for testing BASIC auth, is to use cURL. Here are some examples of testing with cURL.
Test without credentials
To test that you resources are being protected, you can use this command to access them without credentials. The request should return an HTTP 401 Unauthorized request and the "WWW-Authenticate" header should indicate basic authentication is required.
curl -vv https://your.domain.name/
Test with credentials
To test that authentication is working correctly, you can specify a set of credentials for authentication. The request should be sent with an "Authorization" header and given that your credentials are valid it should authenticate. If your credentials are invalid you should be presented with a HTTP 401 Unauthorized message. If the user is authenticated, but does not have access to view the resource you should be presented with an HTTP 403 Forbidden message.
curl -vv -u bcsguser:password https://you.domain.name/
A couple notes about cURL.
The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.25
This release includes numerous bug fixes and several new features compared to version 7.0.23. The notable new features include:
I'm in a very interesting situation. I'm validating the migration tomcat 6 to tomcat 7, so we can use the zero donwtime deploy.
That is correct, two different web applications (even the same application deployed twice) generates to different classes, as the same class is loaded by the same class loader.
If you want your cache to remain up, while you redeploy the application, you would also have to extract the classes stored in the cache, remove them from the WAR and deploy those classes into tomcat's lib directory instead. These classes wont be reloaded, nor will they change.
We are trying to deploy 2 versions of the same application on Tomcat 7 to test its parallel deployment features for our application.
Not meeting with success, I was looking for a definitive guide for parallel deployment on Tomcat 7.
Our application is a JSP based application but we can have changes often.
The definitive reference for parallel deployment comes directly from the Apache Software Foundation: http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment.
Additionally, Mark Thomas wrote a summary article explaining how this feature works on the Context Container and across clusters: http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7.
Yes, this feature has been available in tomcat for a while.
You would create multiple <Host> elements
2011 has been a great year for the Tomcat Expert community. After almost 2 years of operating, the Tomcat Expert has hit its stride, unloading an array of new information, as well as keeping you up to date with the newest releases for Apache Tomcat 6 and Apache Tomcat 7. With the addition of two new Tomcat Expert Contributors, (Channing Benson and Daniel Mikusa), the Tomcat Expert community continues to build on its reputation for being the leading source for fresh perspectives and new information on how to best leverage Apache Tomcat in the enterprise.
I enabled setTestonBorrow() without specifying the validation query. I had seen the documentation of the jdbc pool, which mentions about setTestonBorrow() as below:
“NOTE – for a true value to have any effect, the validationQuery parameter must be set to a non-null string.”
I actually tested the application with this setting, and could not find any issue. But in real scenario (since the borrowing of the connection from the pool was in large numbers), the TCP/IP connections between the server and the database peaked.
Given that this is not really a question, but more of an observation followed by a feature request. I would suggest that you try the following steps. They should help you to properly log your request.
 - https://svn.apache.org/repos/asf/tomcat/trunk/modules/jdbc-pool/
 - https://issues.apache.org/bugzilla/
 - https://tomcat.apache.org/lists.html
 - https://tomcat.apache.org/getinvolved.html