Social media

Why Tomcat 7 upgarde, and Tomcat 7 Vs Tomcat 6

"

Apache released a new version of 7.0.25, and who used to use previous versions may required to have their TOMCAT upgarded, here I am try to state why you required to be upgrade to Tomcat 7, before describing the reasons to upgrade the tomcat here fist I will explain the main differences between Tomcat 7 and Tomcat 6.    
Difference between Tomcat 7 and Tomcat 6:
Apache Tomcat Server 7
Apache Tomcat Server 6
The latest sub version of Apache Tomcat Server 7 is Apache Tomcat Server 7.0.25.
The last version of Apache Tomcat Server 6 was Tomcat 6.0.35.
Apache Tomcat Server 7 needs Java SE 6 or further version.
Apache Tomcat 6 needs JRE 5.0 or further version.
Apache Tomcat Server 7 can be started quickly and it loads and runs web applications in a faster way.
Apache Tomcat Server 6 is slightly slower when compared to Apache Tomcat Server 7 in starting as well as running web applications.
Security is enhanced in Apache Tomcat Server 7. It has introduced many code fixes and additions for enhancing security. One such security related feature that is available in Apache Tomcat Server 7 is Cross Site Request Forgery (CSRF) Prevention Filter.
The security enhancements introduced in Apache Tomcat Server 7 including CSRF Prevention Filter is not available in Apache Tomcat Server 6.
Apache Tomcat Server 7 includes the Servlet 3.0 API.
Apache Tomcat Server 6 includes Servlet 2.5 API.
Apache Tomcat Server 7 supports Expression Language 2.2.
Apache Tomcat Server 7 supports Expression Language 2.1.
JSP 2.2 API is bundled with Apache Tomcat Server 7.
JSP 2.1 API is bundled with Apache Tomcat Server 6.
Apache Tomcat Server 7 offers tomcat-api.jar which contains interfaces that are shared by the Jasper and Catalina.
Apache Tomcat Server 6 does not provide tomcat-api.jar.
Apache Tomcat Server 7 supports the third party applications that require Servlet 3.0 API.
Since Apache Tomcat Server 6 does not support Servlet 3.0, it does not support the third party applications that require Servlet 3.0.
Apache Tomcat Server 7 provides improved configurability through newly added container components such as AddDefaultCharsetFilter and ExpiresFilter.
Apache Tomcat Server 6 does not include AddDefaultCharsetFilter and ExpiresFilter. It depends upon web applications to resolve the configurability problems.
Apache Tomcat Server 7 code is modernized due to usage of generics in the necessary places.
Apache Tomcat Server 6 code is not as modernized and cleaner as that of Apache Tomcat Server 7.

 Tomcat added additional support to Java Servlet 3.0, JSP 2.2, and EL 2.2 specifications. Tomcat 7 makes it even easier to create ever more complex web applications, including lots of bundled features that we’d have to implement or find third party solutions for. It also improves Tomcat’s already impressive performance and efficiency, which is particularly important in today’s distributed service (and increasingly virtualized) deployment architectures.
Another area that I’m excited about is Tomcat 7’s improved memory leak prevention/detection. Many developers tend to blame Tomcat for their application memory leaks, partly because Tomcat did have some issues in its early days and developer memories are very long and partially because Tomcat did very little to enforce or detect memory leakage in the client code. Basically you had to check server logging, which is FAR more difficult in horizontally scaled, services based, virtualized, deployments…perhaps even impossible.
Many of my clients also pair Tomcat with SpringSource, creating a “SpringSource Server” that is both performant and reliable. Tomcat 7 makes Tomcat an even better platform for frameworks such as Spring.
Servlet 3.0. Servlet 3.0 improves ease of development, extensible, and security. It also adds support for asynchronous programming techniques.
·         Asynchronous Support. Servlet 3.0's asynchronous support has been fully implemented in TC 7. There was async programming in Tomcat 6, but Servlet 3.0 support offers developers a standard interface, improving portability between containers.
·         Dynamic Configuration. Another Servlet 3.0-related feature is Tomcat 7's dynamic configuration functionality. Tomcat 7 provides support for web fragments, so libraries can use an embedded web.xml fragment for configuration, eliminating the need to add library-specific configuration entries to application's web.xml files.
·         Annotation Support. Tomcat 7 also includes Servlet 3.0's new annotation support, offering developers a way to configure filters, listeners, and servlets using declarative style programming. Classes and servlets can be quickly defined by annotating the class, which makes development faster and eliminates the need for deployment descriptors.
·         Extended Servlet API. An extension of the Servlet API enables the programmatic addition of Filters and Servlets when an application starts. Although access to this API while running an application is prohibited in the Servlet 3.0 specification, Tomcat 7 will allow developers to ignore this somewhat controversial limitation if they wish, at the expense of portability.
·          More Servlet 3.0 Features. Other features that developers will appreciate include the use of generics, improved session tracking and SSL session ID tracking for increased security. Also included is a brand new file upload functionality, which will allow developers to upload additional libraries as needed.
Additional Tomcat 7 Features. The fun with Tomcat 7 doesn’'t stop with the Servlet 3.0 specification support. Also included are are:
·          Simplified Embedding. Tomcat 7 includes an API that makes embeddable Tomcat applications a simple, hassle-free reality. Utilizing this new API, developers only need a few lines of code to get Tomcat running within their applications.
·          Improved Logging. Tomcat 7 includes two improvements to its logging system: a single line log formatter to make log files easier to read and an asynchronous file handler. The single line formatter writes logs in a single line, which makes life much easier for IT admins. The asynchronous handler allows Tomcat to write logs to disk in a dedicated thread, so that logging operations do not cause any latency in processing threads.
·          Aliases. This new feature allows inclusion of external file systems or Web Application Archive content within an application, such as images or JavaScript directories, so that shared assets can be centrally distributed across a wide array of web applications. In today’s deployment architectures, this is hugely powerful.
·          Memory Leak Detection/Prevention. Although the bugs in Tomcat's 4.1.x/5.5.x codebase responsible for some of these errors have long been fixed, developers still had trouble eliminating memory leaks caused by their own applications. Tomcat users have historically had problems with memory leaks when reloading web applications throughout the existence of the project, usually manifesting as an OutOfMemoryError for the Permanent Generation. The Tomcat team has been frustrated from time to time by applications that continue to adversely affect perceptions of Tomcat’s reliability. So, they decided to enhance Tomcat to be able to deal with many of the application defects that caused memory leaks. They were able to track down and repair a number of bugs specific to certain Java APIs and they wrote patches for the most common application-caused memory leaks. Applications which previously triggered these leaks can now reload without error and new applications will be covered as well.
·          Improved Security. The Manager and host-manager applications have been made more secure, by splitting privileges into multiple roles. Tomcat 7 also includes blocking to prevent tampering with the Session ID (sometimes called session fixation attacks). There are also now separate roles for script-based, web-based, JMX proxy, and status page access, for more specific access control.
Upgrading
As I noted above, I’ve been playing with Tomcat 7 for some time. I’ve also tried moving a few applications from Tomcat 6. I didn’t avail myself of Servlet 3.0, so my experience so far is more of a “upgrade existing application” rather than “develop new application” scenario. See http://tomcat.apache.org/migration.html for help when you start.

·          OS/Environment. I ran the Tomcat 7 upgrades on RHEL 5 and Java 6. I had some difficulty building Tomcat 7, but I never really figured out why. Suddenly, it just worked, so it may have been pilot error.
·          Tomcat Manager. I personally find Tomcat Manager more trouble than not. I really prefer the commercial management products (such as vmWare/SpringSource and MuleSource, although for very different reasons). That said, I did muddle thru the Tomcat 7 Manager just to see what I thought. The biggest change I found in manager is that manager has been split into multiple console segments, each with its own URL (enabling more detailed privilege management). These are the Web Interface, the Text Interface, the JMSProxy/Servlet, and the Server Status page(s). Each now also has a specific Manager Role associated with it and host manager has likewise been split into multiple roles. This should improve management security, although no where near as much as the aforementioned products.
·          Deployment. This is one of the bigger changes in administration, because the most commonly used deployment—context descriptors contained in WAR files were extracted and deployed into the containing Host's xmlBase— is no longer the default behavior. You can apparently re-enable this if you wish, but for the purpose of the experiments, I did not.
·          Application Behavior. Porting these three applications to Tomcat 7 was pretty straightforward. In the first case, the application “just worked” once I got it deployed and in the second case, I needed to do some tweaking of the configuration. In the last case, I needed to do some recoding because of the use of Hibernate. I haven’t ported any Spring Based applications, but I expect those will go similarly easily…and probably better where additional services such as data persistence are utilized.
·          Application Performance/Reliability. I’ve not done any stress testing yet, but my first impressions are that the applications are at least as stable and just a touch faster. One of the applications—that happens to be well instrumented— runs about 8% faster with Tomcat 7.

 If you like this please spare some time to share and comment for improvement. 



"

Apache released a new version of 7.0.25, and who used to use previous versions may required to have their TOMCAT upgarded, here I am try to state why you required to be upgrade to Tomcat 7, before describing the reasons to upgrade the tomcat here fist I will explain the main differences between Tomcat 7 and Tomcat 6.    
Difference between Tomcat 7 and Tomcat 6:
Apache Tomcat Server 7
Apache Tomcat Server 6
The latest sub version of Apache Tomcat Server 7 is Apache Tomcat Server 7.0.25.
The last version of Apache Tomcat Server 6 was Tomcat 6.0.35.
Apache Tomcat Server 7 needs Java SE 6 or further version.
Apache Tomcat 6 needs JRE 5.0 or further version.
Apache Tomcat Server 7 can be started quickly and it loads and runs web applications in a faster way.
Apache Tomcat Server 6 is slightly slower when compared to Apache Tomcat Server 7 in starting as well as running web applications.
Security is enhanced in Apache Tomcat Server 7. It has introduced many code fixes and additions for enhancing security. One such security related feature that is available in Apache Tomcat Server 7 is Cross Site Request Forgery (CSRF) Prevention Filter.
The security enhancements introduced in Apache Tomcat Server 7 including CSRF Prevention Filter is not available in Apache Tomcat Server 6.
Apache Tomcat Server 7 includes the Servlet 3.0 API.
Apache Tomcat Server 6 includes Servlet 2.5 API.
Apache Tomcat Server 7 supports Expression Language 2.2.
Apache Tomcat Server 7 supports Expression Language 2.1.
JSP 2.2 API is bundled with Apache Tomcat Server 7.
JSP 2.1 API is bundled with Apache Tomcat Server 6.
Apache Tomcat Server 7 offers tomcat-api.jar which contains interfaces that are shared by the Jasper and Catalina.
Apache Tomcat Server 6 does not provide tomcat-api.jar.
Apache Tomcat Server 7 supports the third party applications that require Servlet 3.0 API.
Since Apache Tomcat Server 6 does not support Servlet 3.0, it does not support the third party applications that require Servlet 3.0.
Apache Tomcat Server 7 provides improved configurability through newly added container components such as AddDefaultCharsetFilter and ExpiresFilter.
Apache Tomcat Server 6 does not include AddDefaultCharsetFilter and ExpiresFilter. It depends upon web applications to resolve the configurability problems.
Apache Tomcat Server 7 code is modernized due to usage of generics in the necessary places.
Apache Tomcat Server 6 code is not as modernized and cleaner as that of Apache Tomcat Server 7.

 Tomcat added additional support to Java Servlet 3.0, JSP 2.2, and EL 2.2 specifications. Tomcat 7 makes it even easier to create ever more complex web applications, including lots of bundled features that we’d have to implement or find third party solutions for. It also improves Tomcat’s already impressive performance and efficiency, which is particularly important in today’s distributed service (and increasingly virtualized) deployment architectures.
Another area that I’m excited about is Tomcat 7’s improved memory leak prevention/detection. Many developers tend to blame Tomcat for their application memory leaks, partly because Tomcat did have some issues in its early days and developer memories are very long and partially because Tomcat did very little to enforce or detect memory leakage in the client code. Basically you had to check server logging, which is FAR more difficult in horizontally scaled, services based, virtualized, deployments…perhaps even impossible.
Many of my clients also pair Tomcat with SpringSource, creating a “SpringSource Server” that is both performant and reliable. Tomcat 7 makes Tomcat an even better platform for frameworks such as Spring.
Servlet 3.0. Servlet 3.0 improves ease of development, extensible, and security. It also adds support for asynchronous programming techniques.
·         Asynchronous Support. Servlet 3.0's asynchronous support has been fully implemented in TC 7. There was async programming in Tomcat 6, but Servlet 3.0 support offers developers a standard interface, improving portability between containers.
·         Dynamic Configuration. Another Servlet 3.0-related feature is Tomcat 7's dynamic configuration functionality. Tomcat 7 provides support for web fragments, so libraries can use an embedded web.xml fragment for configuration, eliminating the need to add library-specific configuration entries to application's web.xml files.
·         Annotation Support. Tomcat 7 also includes Servlet 3.0's new annotation support, offering developers a way to configure filters, listeners, and servlets using declarative style programming. Classes and servlets can be quickly defined by annotating the class, which makes development faster and eliminates the need for deployment descriptors.
·         Extended Servlet API. An extension of the Servlet API enables the programmatic addition of Filters and Servlets when an application starts. Although access to this API while running an application is prohibited in the Servlet 3.0 specification, Tomcat 7 will allow developers to ignore this somewhat controversial limitation if they wish, at the expense of portability.
·          More Servlet 3.0 Features. Other features that developers will appreciate include the use of generics, improved session tracking and SSL session ID tracking for increased security. Also included is a brand new file upload functionality, which will allow developers to upload additional libraries as needed.
Additional Tomcat 7 Features. The fun with Tomcat 7 doesn’'t stop with the Servlet 3.0 specification support. Also included are are:
·          Simplified Embedding. Tomcat 7 includes an API that makes embeddable Tomcat applications a simple, hassle-free reality. Utilizing this new API, developers only need a few lines of code to get Tomcat running within their applications.
·          Improved Logging. Tomcat 7 includes two improvements to its logging system: a single line log formatter to make log files easier to read and an asynchronous file handler. The single line formatter writes logs in a single line, which makes life much easier for IT admins. The asynchronous handler allows Tomcat to write logs to disk in a dedicated thread, so that logging operations do not cause any latency in processing threads.
·          Aliases. This new feature allows inclusion of external file systems or Web Application Archive content within an application, such as images or JavaScript directories, so that shared assets can be centrally distributed across a wide array of web applications. In today’s deployment architectures, this is hugely powerful.
·          Memory Leak Detection/Prevention. Although the bugs in Tomcat's 4.1.x/5.5.x codebase responsible for some of these errors have long been fixed, developers still had trouble eliminating memory leaks caused by their own applications. Tomcat users have historically had problems with memory leaks when reloading web applications throughout the existence of the project, usually manifesting as an OutOfMemoryError for the Permanent Generation. The Tomcat team has been frustrated from time to time by applications that continue to adversely affect perceptions of Tomcat’s reliability. So, they decided to enhance Tomcat to be able to deal with many of the application defects that caused memory leaks. They were able to track down and repair a number of bugs specific to certain Java APIs and they wrote patches for the most common application-caused memory leaks. Applications which previously triggered these leaks can now reload without error and new applications will be covered as well.
·          Improved Security. The Manager and host-manager applications have been made more secure, by splitting privileges into multiple roles. Tomcat 7 also includes blocking to prevent tampering with the Session ID (sometimes called session fixation attacks). There are also now separate roles for script-based, web-based, JMX proxy, and status page access, for more specific access control.
Upgrading
As I noted above, I’ve been playing with Tomcat 7 for some time. I’ve also tried moving a few applications from Tomcat 6. I didn’t avail myself of Servlet 3.0, so my experience so far is more of a “upgrade existing application” rather than “develop new application” scenario. See http://tomcat.apache.org/migration.html for help when you start.

·          OS/Environment. I ran the Tomcat 7 upgrades on RHEL 5 and Java 6. I had some difficulty building Tomcat 7, but I never really figured out why. Suddenly, it just worked, so it may have been pilot error.
·          Tomcat Manager. I personally find Tomcat Manager more trouble than not. I really prefer the commercial management products (such as vmWare/SpringSource and MuleSource, although for very different reasons). That said, I did muddle thru the Tomcat 7 Manager just to see what I thought. The biggest change I found in manager is that manager has been split into multiple console segments, each with its own URL (enabling more detailed privilege management). These are the Web Interface, the Text Interface, the JMSProxy/Servlet, and the Server Status page(s). Each now also has a specific Manager Role associated with it and host manager has likewise been split into multiple roles. This should improve management security, although no where near as much as the aforementioned products.
·          Deployment. This is one of the bigger changes in administration, because the most commonly used deployment—context descriptors contained in WAR files were extracted and deployed into the containing Host's xmlBase— is no longer the default behavior. You can apparently re-enable this if you wish, but for the purpose of the experiments, I did not.
·          Application Behavior. Porting these three applications to Tomcat 7 was pretty straightforward. In the first case, the application “just worked” once I got it deployed and in the second case, I needed to do some tweaking of the configuration. In the last case, I needed to do some recoding because of the use of Hibernate. I haven’t ported any Spring Based applications, but I expect those will go similarly easily…and probably better where additional services such as data persistence are utilized.
·          Application Performance/Reliability. I’ve not done any stress testing yet, but my first impressions are that the applications are at least as stable and just a touch faster. One of the applications—that happens to be well instrumented— runs about 8% faster with Tomcat 7.

 If you like this please spare some time to share and comment for improvement. 



1 comments:

Post a Comment

Please write to us here...