in Uncategorized

JSF is Not Fixable

Last week, at the Colorado Software Summit, I gave a session on RESTful Web Apps. In this session, I made a comment that the proponents of JSF failed to consider the web architecture, and that it is not fixable. My goal in that session was to point out the consequences of design choices made by some web frameworks, but not necessarily to point fingers at those frameworks.

Matt Riable attended my session, and shared his notes on his blog at RESTful Web Applications with Subbu Allamaraju. His post incited some comments, to one of which I would like to respond here.

Diego Plentz said that

I haven't come to the conclusion that JSF is not fixable yet. It looks like there are some major overhauls going on related to state saving and RESTful URLs in JSF 2.0.

I think this comment misunderstands what it means to be "RESTful". The ability of an app to create a link that can be submitted via GET to some non-JSF app does not make the app RESTful. Period. I don't have problems with JSF focusing on usability, but I do think it should have paid attention to the web architecture. Given that JSF is a Java standard, those who want to rely on standards have no choice but to build web apps that fail the web architecture and can not take advantage of common web infrastructure. The design choices made in JSF are poor, and I don't see an exit strategy other than dumping the current standard, and going back to the drawing board. Bill de hÓra echoed a similar thought:

But it’s hard to be non-critical about a spec that got things so wrong – not just REST, but basic HTTP usage. A JSF that supports REST is going to be a complete overhaul, no?

I have not read the latest JSF 2.0 draft thoroughly, but upon a quick reading of all the changes, I don't see anything to address the basic web usage. Unless there are more changes coming that will magically fix the core without an overhaul, JSF should the follow JAX-RPC into the JSR-graveyard.

Update:

Looking at some of the heated comments below and the links posted, I can't help but comment that JSF (community) has recently discovered the web architecture, viz., that GET is the de facto means of navigation and that POST is an exception and used solely for unsafe and non-idempotent operations. This is unfortunate for a standard. Secondly, the ability to pass parameters to a URI does not fix JSF as long as JSF's notion of a form is always driven by POST. That does not make JSF a bad framework, it just makes it a special-purpose framework that can be used to build certain kind of stateful applications. That, IMHO, is a too low a bar for a standard framework.

Write a Comment

Comment

19 Comments

    • To elaborate on my previous response, ideally, it should let the app decide when and whether to use POST. Unfortunately, it makes that choice for you. Secondly, it should make it easy for applications to enforce best practices regarding caching, redirect-after-POST etc.

  1. I’m surprised how you assert that JSF simply cannot be changed to do that when Seam has offered this functionality to JSF developers for a long time. The JSF 2.0 expert group has explicitly said that they are going to be standardizing it. It is not in the spec yet, but will be soon.

    I doubt many developers use JSF 1.x on its own. You need Facelets + Seam. With those two it is serious competition to any web framework.

  2. Even IBM says Seam makes JSF RESTful:

    The difference is that links assembled by the Seam component tags issue requests using an HTTP GET operation, rather than the HTTP POST form submission model indicative of JSF. Thus, links created by Seam are “friendlier” to bookmarking and considered to be far more convenient for developers.

    You may also notice that when you use page actions, the URL in the location bar corresponds to the page being shown rather than always being one page behind. (The latter situation occurs because JSF configures forms to post back to the same URL that generated them. The location bar does not get updated to reflect the new view after an action because JSF advances to it through a server-side redirect.) If you really want to demonstrate the flexibility of page actions, you can use them to create RESTful URLs (for example, /faces/product/show/10). To do so, you map the page action method to the view ID “/product/show/*”, where the /faces prefix is the JSF servlet-mapping portion. The page action method then mines the request URL to determine the type of data and the data identifier, loads that data, and then navigates to the appropriate template. This example clearly demonstrates that the one-to-one mapping between a JSF request URL and view template is not imperative.

    http://www.ibm.com/developerworks/java/library/j-seam1/

    And in the JSF 2.0 spec requirements:

    Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used.
    Allow JSF application resources to be accessed via REST.
    Add support for REST (JSR 311)

    http://jcp.org/en/jsr/detail?id=314

  3. Shame on you for spreading uninformed FUD about JSF at the Colorado Software Summit without fact checking. I’m sure you lost credibility to any JSF developers in your audience who uses Seam and knows anything about JSF 2.0.

    You also misinterpreted my comment, and did NOT follow the link I provided in Matt Raible’s blog. No I am NOT talking about HTTP GET links to *non* JSF apps. You are too closed minded and have already made up your mind about JSF.

    • By the way, Seam’s notion of conversational scope does require a session to manage that conversational state. This is perhaps a good compromise given the stateful nature of JSF. Therefore I stand by my comments.

    • Fair enough. As I said before, my comments were solely based on JSF as it exists. If some future version of JSF fixes these problems, well and good. You can flame me for saying that JSF is not fixable, but by being a Java standard, JSF has a much higher bar to cross. That is, it needs to make writing web apps that adhere to the web architecture possible and easy to implement.

  4. Ok, and I will agree that JSF 1.2 needs addons like Facelets, Seam and component libraries to make it competitive. Your blog says JSF is not fixable. The point I am trying to make is that it is fixable, the existing JSF extensions prove it, and they are being standardized in JSF 2.0.

  5. Someone in the JSF expert group told me that fixing state saving is the top most issue being worked on right now. They hope to have it in the public review draft which is due out very soon.

    • Thanks for the update. By the way, the key issue is not necessarily how to manage state, but to allow stateless applications. State management is nice to have when an app needs it, but that should be an option.

  6. Yes. The issue tracker has tickets that talk about making JSF stateless wherever possible, and improving the state saving mechanism for when state is necessary. I look forward to reading about this and full HTTP GET support in the next public draft.

  7. Subbu, I agree with you. Seam, et. al. actually encourages and promotes stateful, session-heavy, web applications. If you’ve ever heard Gavin King’s talks on Seam, you’d see that is one of the first things he tries to hammer into the audience. That a stateful applications are “modern”. Conversations are *central* to Seam and a conversation requires a lot of state on the server in his implementation.

    • Thanks. I never heard him speak, but I found the same from their docs. I don’t understand why the other “Anonymous” commenter was so defensive about JSF. Let’s call a spade a spade.

  8. I use JSF at work as part of maintaining a mature intranet web application. Proxy caching is not possible since we use JSF directly. It has proven so difficult to make our system work on the latest MyFaces release that we have chosen to stick with the old version. I have serious misgivings about a technology standard that fails so badly for existing developers as it matures. While it has proven to be quite useful on getting the application working and in front of customers it has also imposed significant scalability problems.

    JSF encourages a stateful programming model that facilitates unscalable web application designs. I would go so far as to say that it encourages it. JSF can be fixed, but doing so would make it completely incompatible with JSF as we know it today. This would effectively require a complete rewrite of our web application component. Given the obvious lack of attention paid to HTTP in JSF 1.x I intend to do everything in my power to discourage my company from adopting it. I believe that Sun has too many big shot RPC advocates egos on the line to abandon this obviously flawed protocol tunnel they have built on top of HTTP.

    In short I agree with this article completely and say it is time for JSF to go away and stop wasting valuable time and resources.

  • Related Content by Tag