Mark Thomas, SpringSource
- Tomcat 7 Supports …
- Servlet 3.0
- JSP 2.2
- EL 2.2
- Java 1.6
- New major release of Tomcat every time the spec has a major change
- Servlet 3.0
- asynchronous processing
- pluggability
- annotations
- session management
- miscellaneous
- Asynchronous processing
- request processing is synchronous, but the response processing can now be asynchronous
- outline
- start asynch processing
- request/response passed to a new thread
- container thread returns to the pool
- new thread does its work
- allows container threads to be used more efficiently
- when waiting for external resources
- when rationing to a resource
- or any other time when the container thread would be blocking
- allows separation of request and response
- chat applications
- stock tickers
- all filters, servlets, and valves in the processing chain must support asynchronous processing
- not as asynchronous as COMET
- pluggability
- purpose was to improve developer productivity–worry less about application configuration
- annotations
- web fragments
- static resources in JARs
- programmatic configuration options
- pros
- development can be faster
- apps can be more modular
- cons
- fault diagnostics are significantly hampered
- might end up enabling things you don't want or need
- overall, I don't recommend using it for production
- instead:
- get tomcat to generate the equivalent web.xml
- use the equivalent web.xml instead
- can be frustrating to figure out what's going on when the application is doing things that aren't in web.xml
- JARs can contain their own web.xml
- /META-INF/web-fragment.xml
- essentially same content as web.xml
- rules for determining fragment ordering
- allows JARs to be self-contained
- JARs can also contain static resources
- always used, cannot be excluded by fragment ordering
- non-deterministic if there are duplicate reosurces in multiple JARs
- annotations
- servlets, filters, listeners
- can be placed on any class
- tomcat has to scan every class on application start
- JARs scanned if included in fragment ordering
- can exclude JARs from the scanning process; controlled in catalina.properties
- security, file upload
- placed on servlets
- processed when class is loaded
- file upload has almost–but not quite–the same API as Commons File Upload
- don't have to ship commons file upload with your apps anymore
- with annotations the configuration can become a lot more opaque
- can turn all of this off in your main web.xml–turn off metadata complete
- this is all or nothing–can't pick and choose what bits you want on or off
- servlets, filters, listeners
- programmatic configuration
- allows a subset of things you can do in we.xml
- add servlets, filters, and listeners
- change session tracking
- configure session cookies
- configure security
- set initialization parameters
- allows greater control / optional configuration
- some environment-specific settings
- can make troubleshooting difficult–no xml to refer to in order to see what's going on
- main advantage is doing things like if/thens in your configuration which you can't do in web.xml
- allows a subset of things you can do in we.xml
- servlet 3.0 – session tracking
- adds tracking via ssl session id
- must be used on its own
- allows selecting of supported tracking methods
- url, cookie, ssl
- url based tracking is viewed as a security risk
- can't turn this off in servlet 2.2, but can turn it off in servlet 3.0
- another release of tomcat 6 will likely allow this to be turned off
- session id is cryptographically secure — can't be spoofed
- adds tracking via ssl session id
- servlet 3.0 – session cookies
- can control default parameters for session cookies
- name – may be overridden by tomcat
- domain – may be overridden by tomcat
- path – may be overridden by tomcat
- maxage
- comment
- secure – may be overridden by tomcat
- httponly – may be overridden by tomcat
- can control default parameters for session cookies
- servlet 3.0 – misc
- httpOnly
- not in any of the specs
- however, widely supported
- prevents scripts accessing the cookie content
- provide a degree of xss protection
- programmatic Login
- useful when creating a new user account
- can log the user in without redirecting them to the login page
- allows the application to trigger a login
- httpOnly
- jsp 2.2
- propery group changes
- can specify default content type in jsp-config
- can specify the buffer size for a page
- new feature – error-on-undeclared-namespace
- e.g. if you have a typo when using a tag library it fails silently
- with error-on-undeclared-namespace turned on, error is thrown at compile time
- jsp:attribute adds support for the omit attribute
- ESL 2.2
- now possible to invoke methods on a bean
- correctly identifying the intended method is tricky
- likely to be some differences between containers–spec if unclear on behavior
- tomcat tries to do what the java compiler does
- other tomcat 7 changes: management
- add the ability to fix the remote jmx ports
- previously jmx picked a port at random
- single line log formatter
- manager app can distinguish between primary, backup, and proxy sessions (for clusters)
- aligned mbeans with reality (GSoC 2010)
- general improvements to JMX support
- can now have a server.xml with just a <Server …/> element and create a fully working Tomcat instance (Hosts, Contexts, etc. all via JMX)
- can't save this config out but that's being worked on
- can now have a server.xml with just a <Server …/> element and create a fully working Tomcat instance (Hosts, Contexts, etc. all via JMX)
- add the ability to fix the remote jmx ports
- performance
- unlikely to see a big change
- can limit the number of JSPs loaded at any one time
- useful for development
- not many areas where tomcat needs a big performance boost
- security
- generic CSRF protection
- if you go to a site with malicious code, might trigger your browser to make a call to the tomcat manager to deploy an app that gives access to your machine
- now the manager looks for a token that was passed from the previous response to the manager app and if the token doesn't exist, the request will fail
- separate roles for manager and host manager apps
- session fixation protection
- changes session ID on authentication
- enable the LockOutRealm by default (e.g. lock out user for 10 minutes after 5 failed login attempts)
- enable an access log by default
- added ability to disable exec command for SSI
- generic CSRF protection
- code cleanup
- use of generics throughout
- removed deprecated and unused code
- reduced duplication, particularly in the connectors
- better definition of the lifecycle interface
- added checkstyle to the build process
- if you've written your own custom tomcat components, you might need to change them for tomcat 7
- extensibility
- added hooks for rfc66 – used by virgo
- refectored to simplify geronimo integration
- significantly simpler embedding
- stability
- builds on tomcat 6
- tomcat 6 is already very stable
- significant reductions in the open bug count
- 6 open bugs without patches when i wrote this slide
- for tomcat 5.5.x, 6.0.x, and 7.0.x combined
- added unit tests
- CI using BIO, NIO, and APR/native on every commit
- memory leak detection and prevention
- back-ported to tomcat 6
- flexibility
- copying of /META-INF/context.xml is now configurable — can control whether or not the expansion/copying of this file happens
- alias support for contexts
- map external content into a web application
- keeps tomcat from deleting things in a symlink when the app is undeployed
- shutdown address is now configurable
- deliberately limited to localhost by default
- tomcat equivalent of some httpd modules
- mod_expires
- mod_remoteIP
- tomcat 7 status
- passes servlet 3.0 TCK with every combination of connectors
- passes jsp 2.2 TCK
- passes EL 2.2 TCK
- all with the security manager enabled
- note that just because it passes the TCK doesn't necessarily mean it's fully compliant
- 7.0.4 just released today
- when will tomcat 7 be stable?
- when three +1 votes come from committers
- in practice the committers each have their own criteria
- i'm looking for 2-3 releases with …
- no major code changes that might cause regressions
- tcks all pass (already have this)
- no major bugs reported
- good levels of adoption (already have this)
- tomcat 7 plans
- one release every month
- bug 49884 put a spanner in the works
- stable by the end of the year?
- keep on top of the open bugs
- work on bringing the open enhancement requests down
- if all goes well, 7.0.6 will be the stable release
- jsr 196 implementation?
- authentication SPI for containers
- geronimo has most (all?) of this already
- windows authentication
- looking unlikely — too much baggage
- needs some native libraries for it to work well
- waffle project already does this
- looking unlikely — too much baggage
- simpler jndi configuration for shared resources
- no more <ResourceLink … />
- more jmx improvements
- further improvements to memory leak protection
- continue migration from valves to filters
- java ee 6 web profile
- no interest so far from user community
- had more questions from journalists than users
- no plans at present
- adds a lot of baggage that isn't that useful
- if you want a web profile implementation, there's geronimo
- one release every month
- useful resources
- new feature — rolling update/side-by-side deployment
- can deploy a new version while the app is running and when a user's session expires, they hit the new version of the app
- came out of a tc server requirement but made more sense to implement it in Tomcat
- springsource providing patch to ASF and will be part of a future tomcat release
- deploy a new WAR with the same name as an existing app, but add ##N at the end of the war file name where N is the version (e.g. myapp##1.war will be a new version of myapp.war)
- context path is retained, meaning context path is the same for both versions of the app
- feature that will be added is when no more sessions are active on the old version it will be automatically undeployed