JSR 315: Java Servlet 3.0 Specification under review at JCP

Discussions

News: JSR 315: Java Servlet 3.0 Specification under review at JCP

  1. Something new to watch! JSR-315, the Servlet 3.0 specification, has been proposed and is under review. This contains a lot of interesting bits in it - the ability to programmatically log in and out, configuration through annotations, asynchronous communications... ftw! Here's the full list of potential considerations for the JSR:
    • Web framework pluggability.
      • Almost all of the Java based web frameworks build on top of servlets. Most web frameworks today plug in either through servlets or through web.xml. Annotations to define some of the servlets, listeners, filters will help in making this possible. Programatic access to web.xml and dynamic changes to configuration of a webapp are desired features. This JSR will aim to provide the ability to seamlessly plugin different web frameworks into web applications.
    • EOD
      • Annotations - use of annotations for the declarative style of programming.
      • As part of the EoD effort the goal is to have zero configuration for web applications. The deployment descriptors would be used to override configuration.
      • Generics - Use generics in the API where possible.
      • Use of other language enhancements where possible to improve the usability of the API.
    • Async and Comet support
      • Non-blocking input - The ability to receive data from a client without blocking if the data is slow arriving.
      • Non-blocking output - The ability to send data to a client without blocking if the client or network is slow.
      • Delay request handling - The comet style of Ajax web application can require that a request handling is delayed until either a timeout or an event has occurred. Delaying request handling is also useful if a remote/slow resource must be obtained before servicing the request or if access to a specific resource needs to be throttled to prevent too many simultaneous accesses.
      • Delay response close - The comet style of Ajax web application can require that a response is held open to allow additional data to be sent when asynchronous events occur.
      • Blocking - Non-blocking notification - The ability to notify push blocking or non-blocking events. Channels concept - The ability to subscribe to a channel and get asyncronous events from that channel. This implies being able to create, subscribe, unsubscribe and also apply some security restriction on who can join and who cannot.
    • Security
      • Ability to login / logout.
      • Self registration.
    • Alignment
      • Alignment / requirements from REST JSR (JSR 311).
      • Alignment / requirements from JSF 2.0 JSR.
    • Misc
      • Better welcome file support.
      • ServletContextListener ordering.
      • Container wide definition for init params.
      • File upload - progress listener - where to store interim and final file.
      • Clarifications of thread-safety issues.
    This is great stuff - EJB has been revitalized through the use of annotations, and the servlet API needs something like this. Annotations finally seem to be coming into their own, and the whole "Web 2.0" idea is finally changing the core APIs we have to deal with.
  2. Servlet Rules![ Go to top ]

    The buzzword hypes come and go, but a good framework/technology like Servlet has been and will be around forever.
  3. Re: Servlet Rules![ Go to top ]

    Can the latest specification have feature in deployment descriptor that would make application unavailable and serve a custom application not available page, such feature is good to have when you are upgrading the application and some one from content management team has to be involved to post the application not available page on webserver. I think this feature is available in .NET Thanks Mittal
  4. Re: Servlet Rules![ Go to top ]

    The buzzword hypes come and go, but a good framework/technology like Servlet has been and will be around forever.
    Yes you can say if a technology is there to stay if it still is there and used after five years, you can say it is done well if it still is there after 10 years without too many complaints and replacement trials. Servlets are such a case, they basically are the roman alphabet of web programming. Simple but universally adaptable and bend into every direction. I hope they will keep the keep it simple approach.
  5. It would be great have the ability to define HTTPS for the login page. After a successful logon HTTPS should be turned back to HTTP. Another great help would be have the login exception and username available for login error page.
  6. I have blogged at length about the asynchronous considerations of JSR-315 from the Jetty point of view. I believe the listed considerations have captured all the key use-cases (and perhaps a few less-key ones) and that finding a cross server solution for them will be a huge step forward for servlets.
  7. Like everyone else, I'm very glad to see this proposal out there, and I'm looking forward to the Servlet API 3.0. My biggest concerns are around the pluggability of web frameworks and the limitations of web.xml, so I'm glad to see those addressed. However, the simple wording for security upgrades concerns me a bit. Container-managed security really needs an overhaul, and this looks more like a minor upgrade... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
  8. However, the simple wording for security upgrades concerns me a bit. Container-managed security really needs an overhaul, and this looks more like a minor upgrade...
    Yup I'm 100% here. Basically, at a minimum, they need to expose the "Programmatic Login" capabilities that every container on the planet implements in some different way. Having the ability to set up a proper Security Context that the container is aware of entails a large amount of hoop jumping. But I think the nail in the coffin for the current Servlet Securiy model is OpenSSO. OpenSSO is a Sun product, run by Sun guys, against Sun/Java specs on Sun servers. It does single sign on. And does it extend container security to work? Nope! It does a generic Servlet Filter (like everyone else on the planet). It calls a programmatic login, I believe, but basically it just goes to show that the model they use doesn't work in the real world, it's not flexible enough. So, basically, they need to extend the container security model to make it able to do things like SSO, "Remember Me", and such, as well as easily letting users create such things in a standard portable way.
  9. It seems that lots of new stuff has been introduced in servlet 3.0 spec. jYog
  10. The spect should be added by: "The form based login could be invoked without requesting a protected web resource before". In the servlet 3.0 early draft they still write: 13.5.3 [...] When a user attempts to access a protected web resource, the container checks the user’s authentication. [...] I would like to have the login form first, maybe on every site, or on the front page. But right now i first have to send the user to a protected resource befor the post from the login form will be accepted.