Discussions

News: Servlet 3.0 Public Review

  1. Servlet 3.0 Public Review (38 messages)

    Greg Wilkins from the blogged about the JSR-315 Public Review of the Servlet 3.0 Specification:
    "JSR-315 has produced a Public Review (PR) of the servlet 3.0 specification, which unfortunately is a poor document and the product of a discordant expert group (EG) working within a flawed process.[...] Significant effort has been put into the PR proposal [...] but unfortunately it has become a Frankenstein monster, cobbled together from eviscerated good ideas and misguided best intentions. The 8 methods of the ED proposal that were rejected as being too complex and confusing have been replaced by 20 methods and 3 new interfaces! [...] The EG is desperately in need of community feedback and probably another round of Public Review after a beta RI is made available."

    Threaded Messages (38)

  2. Re: Servlet 3.0 Public Review[ Go to top ]

    This spec is surely something worthless. Why not use the JAX-RS Api as the Servlet 3.0 spec ??
  3. Complete disaster[ Go to top ]

    This JSR is a complete disaster. It solves almost NO real problems, but adds a lot of crap. Servlets are now used as a foundation for other web-frameworks. So we DON'T need annotation-based configuration, we DON'T need automatic discovery. We don't need other crap. For example, who has ever used role-based security model of J2EE? Anyone? Please, give us a reliable foundation. We need problems with concurrent access to HttpSession to be solved, as HttpSession is horribly broken right now. And asynchronous servlets in JSR are at best a half-hearted attempt.
  4. Re: Complete disaster[ Go to top ]

    For example, who has ever used role-based security model of J2EE? Anyone?
    I think we tried using it once. It wasn't worth the effort. The best (most comprehensive) way to deal with security I've seen is to use URL patterns to block/allow access.
  5. you should give it another shot[ Go to top ]

    especially if you are using an Java EE 1.4 compatible or later Servlet container.
  6. Re: Complete disaster[ Go to top ]

    James +1 In the many JEE projects I have worked on I have not seen a practical JEE role-based security impl. While URL patterns are a great top-level application of security roles/privs there are also the lower levels: - Interception - behavioural (changing workflow) - Presentation (showing, hiding or otherwise changing visual component presentation. But that could be a whole other thread. - Gary
  7. Re: Complete disaster[ Go to top ]

    James

    +1

    In the many JEE projects I have worked on I have
    not seen a practical JEE role-based security impl.

    While URL patterns are a great top-level application
    of security roles/privs there are also the lower levels:

    - Interception
    - behavioural (changing workflow)
    - Presentation (showing, hiding or otherwise
    changing visual component presentation.

    But that could be a whole other thread.

    - Gary
    Good point. It would probably be a better thread. This one makes me feel depressed.
  8. Re: Complete disaster[ Go to top ]

    This JSR is a complete disaster. It solves almost NO real problems, but adds a lot of crap.

    Servlets are now used as a foundation for other web-frameworks. So we DON'T need annotation-based configuration, we DON'T need automatic discovery. We don't need other crap.
    If you don't need the annotation base configuration and automatic discovery don't use it. You can still continue doing what you did earlier. Specify everything in the descriptor. However don't come and complain about having to use the descriptor to specify everything. That's the problem we are trying to solve and have the framework authors be able to define everything in their jars so that you as a developer don't have to have boiler plate configuration put in your descriptor every time you use the framework.


    For example, who has ever used role-based security model of J2EE? Anyone?

    Please, give us a reliable foundation.
    Do you have a better solution? Please send it to the feedback alias at jsr-315-comments at jcp dot org and I will be happy to send it to the EG.
  9. Re: Complete disaster[ Go to top ]

    However don't come and complain about having to use the descriptor to specify everything. That's the problem we are trying to solve and have the framework authors be able to define everything in their jars so that you as a developer don't have to have boiler plate configuration put in your descriptor every time you use the framework.
    Currently my web.xml file is just 23 lines, last modified more than a year ago. And that's not an unusual situation. However, bloated spec will (probably) require more bloated container. As for security support - just throw it out completely (maybe retaining existing security support for compatibility). Give us an API to hook into. If you insist on adding some explicit support, then at least look how Acegi Security manages to do it. As for other low-level stuff, it would be nice to have some ways to control caching behavior of application servers. For example, IIS on Windows has an uber-efficient kernel cache. It would be nice if we could specify, say: ---------------------- /images/* FOREVER NONE ---------------------- And application server then will start serving image files from its super-efficient cache.
  10. Servlet 3.0 is not final yet. You are reacting to the Public Review Draft. The EG also plans to include some minor but significant enhancements to the security-constraint syntax, to add new login and logout apis, to add support for the common security annotatuons, eg. @RolesAllowed etc, and to require common compatible implementation of the constraint model. We will also be recommending that Servlet containers support standard authentication mechanism pluggability.
  11. The EG also plans to include some minor but significant enhancements
    I'm sorry, but these enhancements are in 'some more crap' category in my book. They are in no way major and in no way make the spec better. It would be much better if you split Servlet spec into a low-level only-necessary-features part and a standard web-framework with fancy annotations built on top of it. Call it, I don't know, "Autumn" or something.
  12. I'm sorry, but these enhancements are in 'some more crap' category in my book. They are in no way major and in no way make the spec better.
    umm...Yea, actually, they do make the spec better. See, here's the neat part. The bulk of what he proposed is built on top of what is already there, it's just exposing it in a standard way, as well as augmenting what's in the web.xml in to the annotations. Amazingly, this is what a lot frameworks do. The beauty of it is that it's backward compatible, meaning your generic 2.5 servlet and web.xml runs just peachy out of the box with no changes. Even better, those generic 2.5 servlets and web.xml can most likely live side by side with the new servlets sans web.xml, or with a minor change. That lets folks preserve the investments they've already made. As for the container security, I am eager to see what finally boils out in terms of improvements. The problems with container security currently are two fold. One, is the static nature of the bindings between groups and roles within the web.xml. When you have reasonably coarse resolution, this works ok. But for anything more dynamic, it fails utterly. Shockingly, (I know this will come as a blow to some), the static model is actually reasonably functional for a wide variety of apps. But there are certainly domains where it's simply is completely untenable. Which leads us to point Two, the current system is not extensible. This means that if you had an application that used the container based security, and you ran in to one of its limitations, all of a sudden all of your security goes to pot. Now many containers had means around these limitations, but those mechanisms are hardly portable. And the standard JEE mechanisms (notably JAAS) were entirely unsuitable to the servlet domain. Opening up the container subsystem to some extensible mechanism will be very nice. There's nothing implicitly wrong with the JEE model of users and roles. In then end, it all boils down to the same problem "can user X perform operation Y" when Y means post an invoice, view some data, or load a web page. The problem become a matter of management. There's nothing particularly wrong with 'request.isUserInRole("POST_INVOICE")'. At the same time, however, 'request.isUserInRole("/bboard/viewPost?postId=1234")' is absurd, especially in terms of the current model. But, at the core, the question and the answer is the same. The problem with the current system isn't so much that it couldn't answer the latter question, as much as it's simply impossible to manage the users/"roles" relationship. No one is going to put "every different page" in their web app in the web.xml. So the real problem isn't the question asked, obviously "role" is not necessarily the appropriate term all the time, but how the question is answered, and how that is managed. It's not the specs role to provide management, beyond something basic (like the current File realms), but to provide mechanisms to let the developers insert their own management in to the container. The current realms system is inadequate because it works solely off of a simple map (user -> list of roles), which the container then interprets. We as developers can provide our own realms to provide users with lists of roles, but have no influence over how that data is interpreted by the container. That's a gaping hole. I know there is a new module for containers, notably Glassfish, that folks can plug in to that I think give us more flexibility than the current JAAS and other mechanisms (the name escapes me at the moment, however). Ideally, the entire workflow of container security will be opened up to allow developers access. It would be even nicer is if we can actually use the applications themselves in this role (for example, today a realm is outside of your application and part of the container, which has it's own issues). Now some will say "Why bother at all when we can, and have, done it all by our selves, particularly for so long?" Because, for simple applications, container security works, and works well. It's, well, simple. And it would be nice as the complexity of the application grows you don't have throw out your security model because you ran in to a container or workflow limitation. It's nice in JEE that you can do isUserInRole at the web tier and all the way back in to the EJB tier, using the same shared Principal across both tiers, even when the EJB tier is remote, all stemmed from the same originating request. You get that "for free". Hopefully, we'll solve this problem we've had for years once and for all, in a sustainable way.
  13. As for the container security, I am eager to see what finally boils out in terms of improvements.
    Me too! One of the things which is really a must for me for this beast to become usable is a possibility of getting the information what are all roles of given user so I can e.g. pass it in queries to database... Other thing: To be able to manage list of role and users outside the application and certainly not to be required to hardcode them in web.xml manolox
  14. Re: Complete disaster[ Go to top ]

    Currently my web.xml file is just 23 lines, last modified more than a year ago. And that's not an unusual situation. However, bloated spec will (probably) require more bloated container.
    Instead of completely bashing the idea and saying its worthless, we should be lobbying to at least be able to limit the things scanned for annotations and for web.xml fragments/framwork pluggability. The current embodiment calls for a bloated container or a container without any flexibility to use annotations. Accidentally exposing a servlet is a much bigger deal than accidentally deploying an EJB. Its all or nothing and puts an even bigger burden on someone trying to use annotations because they have to verify every single jar they are using to see what its trying to deploy which defeats the purpose.
  15. Re: Complete disaster[ Go to top ]

    This JSR is a complete disaster. It solves almost NO real problems, but adds a lot of crap.


    Servlets are now used as a foundation for other web-frameworks. So we DON'T need annotation-based configuration, we DON'T need automatic discovery. We don't need other crap.


    If you don't need the annotation base configuration and automatic discovery don't use it. You can still continue doing what you did earlier. Specify everything in the descriptor. However don't come and complain about having to use the descriptor to specify everything. That's the problem we are trying to solve and have the framework authors be able to define everything in their jars so that you as a developer don't have to have boiler plate configuration put in your descriptor every time you use the framework.



    For example, who has ever used role-based security model of J2EE? Anyone?

    Please, give us a reliable foundation.


    Do you have a better solution? Please send it to the feedback alias at jsr-315-comments at jcp dot org and I will be happy to send it to the EG.
    What we really don't need is a new spec requiring a lot of work to be implemented or to learn. About security, I would turn back the sentence: if you don't have a better solution, drop it. Give us a standard way to plugin an application (beware, application not container) provided implementation for both authentication and authorization. And I don't think that the EG would need my suggestion to realize that **this** way of specifying something is the right way.(Well, if it would really be the case, I would be seriously concerned) It simply not convenient. And the same applies to class loading. It is still a recommendation that webapp comes first. Making it mandatory, I understand that could cause trouble to some popular containers. So, the real question is: is JCP/JSR and all this paraphernalia something to ease developers life or to put a "compliant with" brand in front of some sleek product ? Guido
  16. Re: Complete disaster[ Go to top ]

    >For example, who has ever used role-based security model of J2EE? Anyone?
    We do, all the time. It's limited, but for its domain, it works great. And with JEE we get "free" propagation back to the EJBs as well. The biggest sore point was that as developers we had no, official, access to it so we could do things like our own log in mechanism, like "remember me" and such. We've used both, and for simpler apps I have no problem with container security, and improving it will be a great boon.
  17. Re: Servlet 3.0 Public Review[ Go to top ]

    This spec is surely something worthless.
    This is not very constructive feedback.
  18. Re: Servlet 3.0 Public Review[ Go to top ]

    Here's the link to the blog: http://blogs.webtide.com/gregw/entry/servlet_3_0_public_review
  19. Re: Servlet 3.0 Public Review[ Go to top ]

    Here's the link to the blog:

    http://blogs.webtide.com/gregw/entry/servlet_3_0_public_review
    editors++
  20. Re: Servlet 3.0 Public Review[ Go to top ]

    There's a lot of stuff here to digest but one thing that pops out at me is this:
    This public draft of the servlet-3.0 represents a thought experiment in API design unhindered by the complexities of implementation, trial usage or community feedback.
    If true, this JSR should not be approved. Specifications that are created this way are almost always disasters.
  21. Re: Servlet 3.0 Public Review[ Go to top ]

    Don't take Greg's blog literally. He is not representing the work of the servlet expert group appropriately. He is making it more of a political scenario against JCP.
  22. Re: Servlet 3.0 Public Review[ Go to top ]

    The Java community should realize that this is one of the few ways we can really "break" Java. Damaging what is the greatest success story for Java, the servlet, can kill the platform. Many other blunders, such as EJB, have not been very important. The usage of many packages was specialized and restricted anyway. Servlets, though, are the common starting point for Web development in Java. At present they are easy to understand and implement. If you screw up servlets and make them hard to understand or implement, you'll lose the Java development community much faster than you might think is possible. Watch out, people. This one is starting to sound like real trouble.
  23. Re: Servlet 3.0 Public Review[ Go to top ]

    This is Rajiv - the servlet 3.0 spec lead. Please see my blog at http://weblogs.java.net/blog/mode/archive/2008/12/rebuttal_of_gre.html. Also please send any feedback that you want about the JSR to the jsr-315-comments at jcp dot org.
  24. Asynchronous HTTP done properly[ Go to top ]

    Hi, The Servlet API has always been a bit rough around the edges, I've wrote several Servlet Containers from version 2.1. To a recent implementation of a Servlet Adaption Layer for the Simple HTTP engine [1] based on 2.5. I think the way to handle asynchronous processing is to make the request and response events, totally abstracting the user the I/O concerns of the container. The start() resume() method is awful and the async context when looking it to is is even worse. Why make Servlets more than they need to be. All you need to do is hide the complexities of the transport from the user. If you want to see an example of a truly high performance asynchronous HTTP engine (with a Servlet Adaption Layer based on Servlet 2.5) then check out Simple at the following address: http://www.simpleframework.org/ If far out performs Jetty, and AsyncWeb from benchmarks I've done. Also, smashed Grizzly, and ill bet any other Servlet Engine proving the service model adopted. http://www.simpleframework.org/performance/comparison.php http://svn.sourceforge.net/viewvc/simpleweb/trunk/application/Plotter/ApacheBench/ScalabilityApacheBench.png?revision=937&view=markup Just my two cents, keep it as simple as possible and allow other projects to build on the basic building blocks. Niall
  25. Niall, the are multiple asynchronous concerns at play here. The ones you are talking about are asynchronous IO concerns, ie how to avoid blocking while reading requests and writing responses. But these are not the asynchronous concerns that servlet 3.0 is trying to address. It is trying to address the blocking that occurs when an application blocks waiting for an available JDBC connection, or blocks waiting for a response from a remote web service or blocks waiting for an application event (eg chat). Servlet 3.0 is trying to find a way that the available asynchronous APIs for these types of activities can be used and free the thread allocated to the servlet request. The general pattern is to:
    • receive the request and decode it's parameters
    • request the slow/scare resources (eg make WS request, queue for JDBC connection on connection pool
    • suspend request and wait after returning thread to container.
    • slow/scare resource becomes available and the request is resumed.
    • request proceeds as before and finds slow/scare resource available, so it generates a response using normal servlet mechanism.
    Note the servlet may still block doing IO, but that is not the concern of the current servlet spec for 3.0
  26. Hi,
    the are multiple asynchronous concerns at play here. The ones you are talking about are asynchronous IO concerns, ie how to avoid blocking while reading requests and writing responses.
    No, absolutely not. I am talking about exactly the same thing. I am talking about asynchronous behaviour as it relates to the service model. The service model Simple uses does not couple request completion to the servicing thread. It is an event in the sense that you can hand the request and response to another thread, put it in to a queue, or create a completion handler like so: public class MyCompletionHandler { public void whenFinishedJdbcStuff(Request req, Response resp) { // go ahead and do whatever, create view etc.. } } Simple has be capable of an asynchronous service model for a few years. Its implementation as I said is far cleaner than both suggestions. Not only can you take control of request completion, but the server it self can parallelize request execution by monitioring the underlying HTTP traffic. All transparent to the developer. If you wanted you could implement suspend() resume() on top of the service model implemented in Simple, it would take 5 mins. This way you can use the suspend() resume() continuations if you wanted, wile remaining free to choose any other asynchronous service model you wanted. Niall
  27. Niall, it's great that new APIs are being developed to handle HTTP request asynchronous. It's even better that they handle more than just async IO. But that still does not mean that we should not make some async services available to those that have investment in the existing APIs of filters and servlets. I believe that serlvet 3.0 should focus on allowing async waiting for events before generating a response using more or less standard servlet frameworks and techniques. In parallel, I'm very supporting of efforts to produce entirely new APIs that may eventually totally replace filters/servlets.


  28. No, absolutely not. I am talking about exactly the same thing. I am talking about asynchronous behaviour as it relates to the service model. The service model Simple uses does not couple request completion to the servicing thread. It is an event in the sense that you can hand the request and response to another thread, put it in to a queue, or create a completion handler like so:


    public class MyCompletionHandler {

    public void whenFinishedJdbcStuff(Request req, Response resp) {
    // go ahead and do whatever, create view etc..
    }
    }


    Simple has be capable of an asynchronous service model for a few years. Its implementation as I said is far cleaner than both suggestions. Not only can you take control of request completion, but the server it self can parallelize request execution by monitioring the underlying HTTP traffic. All transparent to the developer.

    If you wanted you could implement suspend() resume() on top of the service model implemented in Simple, it would take 5 mins. This way you can use the suspend() resume() continuations if you wanted, wile remaining free to choose any other asynchronous service model you wanted.

    Niall
    How do you use existing content generation frameworks with Simple? If it can't do that, its insufficient.
  29. How do you use existing content generation frameworks with Simple? If it can't do that, its insufficient.
    Just make a classic request-response model on top of it. Or Servlet3-style resume/suspend framework. I have not used Simple, but I've extensively used ACE Framework for more than 10 years. It's easy to build a classic synchronous model on top of asynchronous system.
  30. How do you use existing content generation frameworks with Simple? If it can't do that, its insufficient.

    Just make a classic request-response model on top of it. Or Servlet3-style resume/suspend framework.

    I have not used Simple, but I've extensively used ACE Framework for more than 10 years. It's easy to build a classic synchronous model on top of asynchronous system.
    We see this long term, but Servlet 3.0 is not the place to define this.
  31. I think you forgot to finish? Insufficient for what? Today HTTP is used as a transport for a wide range services from REST or traditional SOAP Web Services. I think you will find for such services performance is paramount, and asynchronous capabilities is fundamental in a multi-tier environment where you need to communicate with networked distributed systems. If you read a little closer you will see that I have written a Servlet Adaptation Layer based on 2.5. Use that if you want to leverage existing component frameworks. If you want to use JAX-RS then its an available HTTP kernel for the Restlet API. http://www.restlet.com
  32. If you read a little closer you will see that I have written a Servlet Adaptation Layer based on 2.5. Use that if you want to leverage existing component frameworks.>
    Can you point me to exactly what you are referring to? I'm not sure what you mean by adaptation layer.
  33. Well just Servlet API build on top of Simple API. So you can use Servlets with as well as the foundation framework, which has asynchronous capabilities. http://www.simpleframework.org/download/4.0.6/ There is a more complete implementation in the subversion repository that has not been released yet. The current download is bundled with the Apache Wicket example WAR unmodified.
  34. Well just Servlet API build on top of Simple API. So you can use Servlets with as well as the foundation framework, which has asynchronous capabilities.

    http://www.simpleframework.org/download/4.0.6/

    There is a more complete implementation in the subversion repository that has not been released yet. The current download is bundled with the Apache Wicket example WAR unmodified.
    I'm not able to download it for some reason. It just seems like you are emulating servlet api's on top of the simple api rather than integrating with a real servlet container that has to work well with the old servlet lifecycle/request-response model.
  35. It may seem like that, but thats not the case. It does not integrate with a Servlet container. It is a Servlet container in every respect, implementing the existing, standardised, Servlet API. It works with the old Servlet lifecycle, it does exactly the same thing as Tomcat or Jetty would.
  36. Hi,


    the are multiple asynchronous concerns at play here. The ones you are talking about are asynchronous IO concerns, ie how to avoid blocking while reading requests and writing responses.


    No, absolutely not. I am talking about exactly the same thing. I am talking about asynchronous behaviour as it relates to the service model. The service model Simple uses does not couple request completion to the servicing thread. It is an event in the sense that you can hand the request and response to another thread, put it in to a queue, or create a completion handler like so:


    public class MyCompletionHandler {

    public void whenFinishedJdbcStuff(Request req, Response resp) {
    // go ahead and do whatever, create view etc..
    }
    }


    Simple has be capable of an asynchronous service model for a few years. Its implementation as I said is far cleaner than both suggestions. Not only can you take control of request completion, but the server it self can parallelize request execution by monitioring the underlying HTTP traffic. All transparent to the developer.

    If you wanted you could implement suspend() resume() on top of the service model implemented in Simple, it would take 5 mins. This way you can use the suspend() resume() continuations if you wanted, wile remaining free to choose any other asynchronous service model you wanted.

    Niall
    Check aync dispatch in ICE (www.zeroc.com). It is there since a very long time. Guido
  37. Re: Servlet 3.0 Public Review[ Go to top ]

    I've read Greg's blog and the rebuttal and stewed on it for a day, and I tend to fear that Greg's view may be the more realistic in terms of the technical issues it raises (can't judge on the process and politics). In particular, his worry over the complexity of catering for "wrappers" in the async facilities does match my own experiences with the existing API. The individual parts of the API seem ok on the surface, but take them in combination (especially any mix of wrappers, request dispatching, and session handling) and you find all sorts of monsters lurking in the deep. If the asynchronous stuff isn't kept as limited as possible and added very, very carefully, I see a future full of odd container-specific behaviour and bugs, and many "clarifications" and "maintenance releases". I also wonder about the timing of the whole "plugability" thing. Now that "Jigsaw" and modularisation is seen as a priority, wouldn't this best be left until after that's sorted out? I know it's early days, but at that point maybe we could re-think the whole packaging story (ears, wars, jars etc), adopt a simpler but more complete and consistent approach across the entire platform, and take this issue out of all the individual APIs. So isn't this the wrong time to be creating yet another API-specific "plugability" solution? Or maybe we should at least try for a common solution to Servlet API "automatic discovery" and how JSP tag libraries and descriptors are found? Hopefully the specification is genuinely still open to feedback (though I can't read it myself, for legal reasons), and the expert group can take the time to get it right. However, the ballot is early-mid January, giving just the minimum period for such public reviews and also being over the Christmas/New Year period. That seems rather short when it's taken so long to get to this point, and given the complexity and potential problems. I guess there's a Java EE 6 deadline to be met, so maybe we're just supposed to say how cool it is and give minor corrections without interfering too much. Then they can get on with adding all the stuff that isn't yet included, before making it "final"...
  38. Here are my *own personal* thoughts: Annotations: I just welcome every move away from xml configuration stuff. From my experience with JAX-WS and metro implementation there is no really a performance penalty. Also about performance I really don't think that webapp start-up time is a big deal as long as it performs well after. pluggability and web.xml fragments: This is also a welcome new addition provided that there is a clean policy about how they all get merged. Accidental Deployment, heh what does it mean? let face it do you deploy anything and everything you get form the net on a live production server? I'll quote Rajiv Mordani from his blog entry: "Or if a framework is authored badly then it shouldn't be used in the first place" No sir! I do believe that a good api should make it hard if not impossible to miss-use it or abuse it. So please think about the integration stuff. We do pass more time integrating disparate bits then coding "from the scratch" solutions. Asychronous Servlets: I keep myself away from since there was no standard way to do. So a standard is welcome in this area. But as (I think) Bill Burke has pointed this better done in the scope of a separate jsr and with the NIO2 jsr in mind. I would be pleased to hear from framework implementers what they think are the impact of those changes on their frameworks. JEE6 EG, where are you? :) Final word for the community: please let change happen :) don't be too septic about radical changes we do need! Warm Regards, Daoud AbdelMonem Faleh.
  39. make it simple[ Go to top ]

    As someone said Servlet is the starting point of using Java for web so please don't create some kind of EJB monster and give java death (oh SUN is already on death bed with $1 stock)