What does the future hold for Servlets?

Discussions

News: What does the future hold for Servlets?

  1. What does the future hold for Servlets? (33 messages)

    Greg Murray is asking for people's thoughts on the future enhancements to the servlet API through his blog entitled "Got Servlets?". While Java EE 5 will provide a maintenance release of the API, Mr. Murray is trying to get a sense for what might lie beyond.

    Some of the suggestions he came up with off the top of his head were:
    • Multipart-Support
    • Improved Security, including programmatic login
    • Self Registration
    • Annotation Support
    Some of these aren't necessarily focused on servlets, which may explain why they're not part of the Servlet API already - but doesn't explain why they're not part of another, more appropriate API (such as a security API for Java EE).

    What suggestions would you have for enhancements to the Servlet API?

    Threaded Messages (33)

  2. This is something that would be a nice addition, and would eliminate the need for klugy workarounds. This is, of course, assuming that a nice API is provided that doesn't require jumping through a ton of hoops, doesn't enforce non intuitive, execution order, etc.
  3. Sometimes we need some custom Protocol, the Interfaces to implement such services are all in place.

    However in my J2EE application.xml I can just say witch web (HTTP) application sits underneath with context-root. No way to say 'I wanna listen to my own protocol on Port X'

    So I need to build my own server with ThreadPools and stuff. Thats a pain.
  4. Sometimes we need some custom Protocol, the Interfaces to implement such services are all in place.However in my J2EE application.xml I can just say witch web (HTTP) application sits underneath with context-root. No way to say 'I wanna listen to my own protocol on Port X'So I need to build my own server with ThreadPools and stuff. Thats a pain.
    Well, it'd depend on the server, but I know of a mailserver that was written as a set of servlets, listening on port 25, so obviously SOME servers can already do it for you.
  5. just like the module types 'java', 'web' and 'ejb' there should be a 'socket' that unlike the 'web' module has no context-root attribute, but a port instead.

    It might be a good idea for application-server vendors to add a posibility to deny the deployment of such modules in hosting scenarios.
  6. 1. implement regex for all url-patterns, the current "matching" is is little value.
    2. better hooks into the security features, declarative security is a great feature, but the authenication shouldn't be server specific and parameters should be modifiable rather than using j_*.
  7. +1 on regexp matching[ Go to top ]

    1. implement regex for all url-patterns, the current "matching" is is little value.
    2. better hooks into the security features, declarative security is a great feature, but the authenication shouldn't be server specific and parameters should be modifiable rather than using j_*.

    I would vote for regexp matching. So many people have asked for the feature over the last 3 years on tomcat-user mailing list.

    peter
  8. Typed request parameters[ Go to top ]

    Strongly typed getters that parsed request parameters based on the browser locale would be nice.

    Ta
  9. Typed request parameters[ Go to top ]

    Strongly typed getters that parsed request parameters based on the browser locale
    not sure i get you, what do you mean by that? strongly type what?
  10. +1 on regexp matching[ Go to top ]

    +1 for both rexexp in URL patterns and both include and excludes (although you could capture both with a single good regular expression, having them seperate is easier)
  11. +1 on regexp matching[ Go to top ]

    1. implement regex for all url-patterns

    Yup yup. +1
  12. +1 on regexp matching[ Go to top ]

    Me too. Current url patterns are too weak. In fact I map my servlet as default (/) and do the url mapping logic there (not very effective - detection of URL means to loop over all regexps and execute them over current URL until there is match. Better idea?)

    I like the idea of multipart request parameters too, but then there would have to be support for error handling (file too large, transfer interrupted, cannot write temporarary file, no space left on device, incorrect mime type ..).
  13. +1 on regexp matchingRe:[ Go to top ]

    Me too. Current url patterns are too weak. In fact I map my servlet as default (/) and do the url mapping logic there (not very effective - detection of URL means to loop over all regexps and execute them over current URL until there is match.

    So tell me this ... why should it be the responsibility of the underlying framework to accomplish this, versus letting the application do so? Surely you can design a filter or servlet that is mapped to the "/*" URL pattern that can accomplish what you need, right?

    The fundamental danger in designing frameworks is that they try to take too much responsibility upon themselves. The use case pointed out in this thread is *exactly* the sort of situation where a standard framework should *enable* a generic solution -- how can a potential future standard *possibly* predict all of the possible scenarios where an application might want to dynaimcally choose different execution resources? IMHO, that's not the job of the HTTP execution framework ... instead, that's the job of some framework built on top (whether that framework is also standardized or not is an orthogonal question). But as long as I can capture "/*" type mappings in my framework layer, I can do whatever I want with the current spec versions.
    Better idea?)I like the idea of multipart request parameters too, but then there would have to be support for error handling (file too large, transfer interrupted, cannot write temporarary file, no space left on device, incorrect mime type ..).

    Multipart request processing, on the other hand, makes sense as something that should be handled at the platform level, IMHO. Although it pales in comparison to my favorite recommendation for Servlet X.Y ... a scope that is longer than a request but shorter than a session :-).

    Craig McClanahan
  14. +1 on regexp matchingRe:[ Go to top ]

    the problem with current matching is that it *looks* like regex and noobies are often caught out when their pattern doesn't match the servlet. URLs are always strings and regex is brilliant for matching patterns and should definitely be part of the spec. I think the question that needs to be asked when considering what needs to be included in the spec is "what will *every* developer using this spec need to do?" and each answer should be included. Pattern matching, as small a point as it is, must be included in the spec, otherwise every developer/team/framework has to write their own. Lets learn something from communities like RoR and DRY!

    I'd also like to be able to add init-params to listeners. Sometimes it isn't desirable to share parameters across the whole context and I've often seen developers use servlets when all they want to do is listen to the context start/stop.

    As tabbed-browsing becomes more popular, "window"-scope will become more and more important. Matt Quail discussed this problem on his blog(Mad Bean) recently. It seems to me as though the problem of sharing sessions across tabs is browser specific (i haven't had time to test it yet), I'm not sure how it could be solved without resorting to javascript code on the client tho. Perhaps someone else has already found a solution to the prolem?
  15. +1 on regexp matchingRe:[ Go to top ]

    Me too. Current url patterns are too weak. In fact I map my servlet as default (/) and do the url mapping logic there (not very effective - detection of URL means to loop over all regexps and execute them over current URL until there is match.

    So tell me this ... why should it be the responsibility of the underlying framework to accomplish this, versus letting the application do so? Surely you can design a filter or servlet that is mapped to the "/*" URL pattern that can accomplish what you need, right?The fundamental danger in designing frameworks is that they try to take too much responsibility upon themselves. The use case pointed out in this thread is *exactly* the sort of situation where a standard framework should *enable* a generic solution -- how can a potential future standard *possibly* predict all of the possible scenarios where an application might want to dynaimcally choose different execution resources? IMHO, that's not the job of the HTTP execution framework ... instead, that's the job of some framework built on top (whether that framework is also standardized or not is an orthogonal question). But as long as I can capture "/*" type mappings in my framework layer, I can do whatever I want with the current spec versions.

    Craig McClanahan

    Good points. I've done exactly that in the past using a baseServlet class, which routes to other servlets. The problem that I encountered is that it can get rather tricky if a developer makes a BaseServlet, which handles the filter/routing and other servlets extend the BaseServlet.

    If the logic isn't implemented correctly, it's very easy to get odd and unpredictable behavior. Having gone through the pain first hand, it's a very easy mistake to make. Having regexp URL matching could potentially make it easier for the simple cases, but for the complex case it wouldn't be any better using a BaseSerlvet mapped to "/*". The times that I've wanted the ability to do regexp URL matching is for quick and dirty debugging purposes. The most recent example I can think of was to debug a webservice.

    Basically, I wanted to use a simple servlet to capture the soap message sent to the server, to verify the soap message is correct. For several reasons, it wasn't easy to dump out the request message from an existing webservice. Depending on the webservice toolkit, dumping the raw request message to a file or some text output can be a pain, especially if the request message is causing a soap parse exception. I think it's atleast worth while to explore idea a bit and see if it is worth while or more trouble than it's worth.

    peter
  16. 1. implement regex for all url-patterns, the current "matching" is is little value. 2. better hooks into the security features, declarative security is a great feature, but the authenication shouldn't be server specific and parameters should be modifiable rather than using j_*.

    This plus more standardization around the semantics of declarative security would be useful. One thing frustrating for me is that you can specify a login-page, but you can't specify a post-login-page or something like that. You have to come up with workarounds to redirect a user to a home page after login. It would be much simpler to just have that out of the box.
  17. Have you looked at CAS?[ Go to top ]

    Take a look at this: http://tp.its.yale.edu/tiki/tiki-index.php?page=CentralAuthenticationService

    It's a single sign on system that's used by Spring. It might give you what you need.
  18. Post Login Page[ Go to top ]

    A post login page is definitely something that would be useful to have. I have had problems with this myself login happens as the result of someone selecting the page from a bookmark or link? The servlet EG is aware of this issue and we will make a note to address this.
  19. Re: Post Login Page[ Go to top ]

    In my applications, besides username and password, a user has to choose which office s/he's logging into. Users have different roles depending on the selected office. This is implementented as a 2-page process, since we only want to show the offices the user is registered to. Could support for this scenario be added? A post login page might not be enough. I would have to share the login handling with the container. Something like JAAS login modules: you have to login to all of them, and each of them has its own "login page". The standard module (either page, ssl, simple, etc) would be just one more login module.
  20. What suggestions would you have for enhancements to the Servlet API?

    One interesting point is that as web frameworks gain ground, these kinds of details become relevant to fewer and fewer people, namely the developers of Struts/Spring/Shale/Tapestry/etc.
  21. Annotations![ Go to top ]

    Something like:

    public class MyServlet .... {

      @EJB PersonManagement personMngt;

      @Inject DataSource myDb;

      @GetMethod public void myOwnDoGet(...) {
      }

      @PostMethod public void myOwnDoPost(...) {
      }
    }


    Also, regex in web.xml mappings, allow to do EXCLUDES servlet-mappings. So:

      <servlet-mapping>
        <servlet-name>...</servlet-name>
        <url-pattern-include>/*</..>
        <url-pattern-exclude>/login</url-pattern-exclude>
      </servlet-mapping>


    Also, add generics to request.getParameter and request.set/getAttribute methods:
    public <T> T getAttribute(Key<T> key);

    So in my servlet I can write:
    Date d = request.getAttribute(Key<Date>.create("loginDate"));

    Or something like it...

    Cheers,
      Arik.
  22. Window Scope[ Go to top ]

    It would be nice to add a window scope that sits between session scope and request scope that is available for a particular window. So if you have three windows open, each will have it's own "window scope" (perhaps frame scope would be a better term for it). It's very problematic using technologies like JSF that store so much in the session when you have multiple windows open.
  23. Unforutunately, the HTTP protocol doesn't tell the server which window a particular request came from. So you'll have to get the HTTP protocol fixed first and then have all the major browsrs implenet the new standard :-)
  24. Go beyond HTTP, SIP[ Go to top ]

    As far as I can tell, the javax.servlet package was intended for generic servlets, and the javax.servlet.http is but one implementation. Later, the concept of a SIP servlet came out through a JSR. But where are all of the others?

    How abotu an SMTPlet? An FTPlet? A Socklet? I presently have the need to intercept some data currently being transmitted to a raw socket on the mainframe. My J2EE app server can handle HTTP just fine, but not a plain socket.

    I'd like the servlet API to at least be plgguable so that you could have various protocol handlers for things like FTP, POP3, SMTP, raw sockets, etc. Or, betetr yet, provide those in the servlet specificationa nd allow vendors to optionally implement them.
  25. Go beyond HTTP, SIP[ Go to top ]

    +100
  26. Re: Go beyond HTTP, SIP[ Go to top ]

    As far as I can tell, the javax.servlet package was intended for generic servlets, and the javax.servlet.http is but one implementation. Later, the concept of a SIP servlet came out through a JSR. But where are all of the others?

    How abotu an SMTPlet? An
    Servlets are not necessarily the best programming model for some of the protocols you list. Specifically it is not clear that servlets are well suited for SIP, which is a peer to peer protocol as opposed to HTTP and FTP, which are client-server protocols. JSLEE is an alternative contaner standard for communications applications over p2p protocols such as SIP and XMPP. It has an open Resource Adaptor architecture, which is IMHO better suited for p2p communications than servlets.
  27. default encoding[ Go to top ]

    Change default encoding from ISO-8859-1 to UTF-8

  28. The HTTP 1.1 spec defines the default as 8859-1 if no encoding has been set see section 3.7.1. As much as I would also like to change this would be have adverse side effects.



    How about an element in the web.xml that would let you set the default encoding for the application? This type of a setting might be better at the container level and the Servlet API does not address that.


    Regarding transaction tokens. This is a pattern referred to as the token pattern and it is used in many web frameworks today. This is a good suggestion for a future version of the Servlet API.
  29. Regarding transaction tokens. This is a pattern referred to as the token pattern and it is used in many web frameworks today. This is a good suggestion for a future version of the Servlet API.

    And maybe this will solve also the "Window Scope" message above. Ok let's free the world from the Amazon bug :-P
  30. History support[ Go to top ]

    I don't know if this is the right term, but "history management" will be great.
    Maybe you've heard about the Amazon bug:
    http://portal.acm.org/citation.cfm?id=568760.568863
    But more simply, if you use back and forward button in the browser most of the times (especially with multi-step applications) you leave the application in an inconsistent state.
    Many web application frameworks try to solve this problem (Spring Web Flow for example), but in fact (correct me if I am wrong) they do not know how to manage a situation like "I clicked 'buy', then press the back button because I did not want to buy, then click 'buy' to another thing because I want to buy it really".
    An history state is, in my vision, something between the session and the request. If you are in session X and state 5 you have some objects, while in session X and state 6 you have some different objects. If you return from 6 to 5 and then make another operation, you can recover the objects and then the real state. This can be managed by adding a parameter automatically to request URLs (just like jsessionid).
    Maybe I have not been very clear, I'm sorry of that :-)
  31. TransactionToken[ Go to top ]

    I think you mean a TransactionToken (struts handles this for instance). A unique id of each request..., generated in the last response.
  32. A getContextPath method[ Go to top ]

    In addition to the ability to query for listening IP address and port, I wish we can have a getContextPath method in ServletContext that returns the context path to which the web application is deployed. You don't always know the context path from within a servlet. We have a web application that is deployed to many different paths in the same box.
  33. Page as a class[ Go to top ]

    Hi,

    I anyone knows WebObjects then you'll be missing one thing:
    Have a page as an own class, so you don't have to deal with the request/response cycle.
    So when calling one page from another, now you pass the vales as request attributes but there is no "contract" betwenn the pages.
    So if you have a page object with getters and setters you can instantiate the page then call the getters to set your attributes and then finally laod the page, much simpler and cleaner.

    Bernhard
  34. SipServlets[ Go to top ]

    For sure the SIP Servlet API is the best example of non-HTTP servlet technology. By the way check out this site for info on SipServlets: https://developer.ubiquitysoftware.com (It even has a free SipServlet container, Eclipse tools, etc).