The JSR-154 aims and early drafts of the 2.4 specification contained an API for programmatic authentication of requests, which was dropped during the review process. While all parties agreed that this is a much needed feature, it was not possible to agree a one-size-fits-all solution without some significant changes to the existing security mechanism. Some of the key questions that need to be resolved include:

These are all tough questions and security is something that you do not wish to get wrong. The result was that programmatic login was thrown into the too hard basket for 2.4. For now programmatic login can be achieved on many containers with a dispatch a request to j_security_check.

The aims of JSR-154 and the early drafts of the 2.4 specification contained a proposal to allow third party extension of the deployment descriptor. The intent was to avoid the need for multiple descriptors when adding container specific deployment.

It is a attribute of J2EE that the standards based deployment descriptors are often insufficient to actually deploy real world applications and that vendor specific descriptors are commonly required. Thus as well as web.xml descriptor, you will commonly see in WEB-INF descriptors such as jboss-web.xml, weblogic.xml, jetty-web.xml, etc.. These extra descriptors provide vendor/container specific configuration for the web application.

The extensible deployment mechanism was intended to allow the vendor specific elements to be added to the standard descriptor without validation issues. Thus the configuration for elements such as EJBs would not be spread over multiple files.

While initially attractive, this proposal was eventually removed for a combination of technical, design and procedural difficulties:

A much requested feature for the servlets API is support for the java.nio library. This is desirable to allow usage of the more efficient direct buffering mechanism as well as potentially using non blocking IO to free threads from the many idle persistent connections that HTTP/1.1 servers maintain.

Unfortunately there is not simple way that NIO can be retrofitted to the servlet API. There is enough chaos and confusion caused by readers/writers vs streams API duality, so adding NIO Channels into that mix is not going to be easy without a major overhaul of the API. It is also not workable to slip non-blocking semantics under the existing API. Most servlets are written expecting blocking IO and will either turn into busy loops or fail if zero bytes because a legal return for a read or a write.

An argument can also be made that moving the Servlets API towards NIO is going in the wrong direction as it will encourage the servlet writer to become more involved with the buffering and scheduling performed by the container. It may be better to increase the level of abstraction provided by the servlet API, so that they can be used more as application components and less as protocol handlers. A higher level of abstraction could allow a container more scope to use efficient mechanisms such as NIO to deal with the low level protocols, which may not be HTTP. For example, the container is already responsible for reading and parsing application/x-www-form-urlencoded content, which it could currently do with NIO behind the scenes. It may be better to extend this approach to allow the container have more responsibility for content reading/writing and let the Servlets focus more on content handling/generation.

While not missing, the SingleThreadModel interface has been deprecated and will go missing in a future release. It was generally agreed that SingleThreadModel was a false friend that allowed a servlet developer to believe that they did not need to be concerned about synchronization and threading. Unfortunately this mechanism only makes this true for instance variables of the servlet itself and does not offer any protection for access to sessions, datasources or any other shared resources. As passing parameters between methods via instance variables is hardly best OO practise, there is no real benefit from this interface. However it does result in some significant additional implementation complications for containers.