Skip navigation

I received an email from core Mojarra team member Jim Driscoll, who was inexplicably laid off from Sun after its recent acquisition by Oracle, about a talk at next week’s BlackHat Conference in Arlington, VA, U.S.A.. Jim pointed out that two security luminaries from the elite SpiderLabs team from Trustwave are giving a talk at BlackHat about view state security, specifically focusing on Mojarra and MyFaces.

Cursory research on the talk found two articles: one by Kelly Jackson Higgins at DarkReading, and another (which appears to be based on the first) at SC Magazine. The talk will be given by David Byrne (the guy who released grendel, not the guy from Talking Heads), and Rohini Sulatycki. For my money, the most important quote in the former article is, “There’s no patch to fix these flaws, either. ‘All developers have to do is perform a configuration change,’ he says, and encrypt view state.”

I haven’t seen their presentation yet, but for Mojarra, you can put lines 16 - 24 of the following web.xml into your web.xml to ensure that client state will be encrypted.

  1. <?xml version="1.0" encoding="UTF-8"?>
  2.     <servlet>
  3.         <servlet-name>Faces Servlet</servlet-name>
  4.         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
  5.         <load-on-startup>1</load-on-startup>
  6.     </servlet>
  7.     <servlet-mapping>
  8.         <servlet-name>Faces Servlet</servlet-name>
  9.         <url-pattern>/faces/*</url-pattern>
  10.     </servlet-mapping>
  11.     <welcome-file-list>
  12.         <welcome-file>faces/index.xhtml</welcome-file>
  13.     </welcome-file-list>
  15.     <context-param>
  16.         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
  17.         <param-value>client</param-value>
  18.     </context-param>
  19.     <env-entry>
  20.         <env-entry-name>ClientStateSavingPassword</env-entry-name>
  21.         <env-entry-type>java.lang.String</env-entry-type>
  22.         <env-entry-value>driscoll</env-entry-value>
  23.     </env-entry>
  24. </web-app>

A zipped netbeans project that does this is available at <>

There’s this guy, Peter Thomas Peter Thomas headshot, and he has this blog entry called “jsf sucks”. I don’t want to increase his page rank so I’m not linking to it here. However, it’s certainly a popular page since it’s the top link for “jsf sucks” on google, bing, and Yahoo!. I have read the entire blog entry, all of the entries linked from it, most of the comments on those entries, and some of the entries linked from those entries. It’s a testament to my faith in God that I can emerge from such an exercise without feeling a level of guilt tantamount to that felt (one hopes) by agenocidaire.

I started doing a quantitative analysis of the comments on each entry, summing up pro- and anti-JSF comments. I only did a spot sampling of four entries in this way and each of them came up with more pro-JSF than anti-JSF comments. I believe that if someone proceeded with such a rotten tomato style analysis, they’d find that most of the entries had more pro-JSF than anti-JSF comments.

The best summary of Mr. Thomas’s vituperous screed coms from Benny Bottema, in one of the comments on one of his posts, which I’ll quote here.

Concerning your point about a ‘comprehensive list of hyper-linked, verifiable references to comments by real people’: I don’t dispute that. I said it is an unbalanced pool of information, poisonous in fact. With ‘nonobjective biased site of propaganda’ I referred to the site owner who compiled the list. Anyone can put together a site, only referring to articles that say something sucks. That’s just immature. Also the names you refer to are irrelevant, old quotes in a time where JSF couldn’t be corrected by supplemental frameworks. Take Rod Johnson’s point for example, it’s a quote from 2004 about JSF. No mention of its potential or combinatorial qualities... simply JSF itself which I already admitted is flawed on its own. And this is used as ‘proper’ argument? Useless propaganda I say.

One sensible response to such polemical fulmination is to tag the articles as appropriate using tags. I have built atag bundle for this purpose. It contains the following tags

Tag nameArticles with this tag express a negative opinion of JSF...
jsf-opinion-negativebut the opinion may or may not be substantiated.
jsf-opinion-negative-reason-complexitydue to its perceived complexity.
jsf-opinion-negative-reason-misunderstandingbut the opinion is based at least in part on a misunderstanding of JSF.
jsf-opinion-negative-reason-misunderstanding-componentsbut the opinion is based on a misunderstanding of how components work JSF.
jsf-opinion-negative-reason-misunderstanding-decorationbut the opinion is based on a misunderstanding of how decoration and extensibility work JSF.
jsf-opinion-negative-reason-misunderstanding-elbut the opinion is based on a misunderstanding of how the EL works JSF.
jsf-opinion-negative-reason-misunderstanding-eventsbut the opinion is based on a misunderstanding of how events work JSF.
jsf-opinion-negative-reason-misunderstanding-i18nbut the opinion is based on a misunderstanding of how i18n works JSF.
jsf-opinion-negative-reason-misunderstanding-lifecyclebut the opinion is based on a misunderstanding of how the lifecycle works JSF.
jsf-opinion-negative-reason-misunderstanding-markupbut the opinion is based on a misunderstanding of how templating and markup works JSF.
jsf-opinion-negative-reason-misunderstanding-persistencebut the opinion is based on a misunderstanding of how persistence works JSF.
jsf-opinion-negative-reason-misunderstanding-renderkitbut the opinion is based on a misunderstanding of how renderkits JSF.
jsf-opinion-negative-reason-misunderstanding-securitybut the opinion is based on a misunderstanding of how security works in JSF.
jsf-opinion-negative-reason-outdatedbut the opinion is based on outdated information.
jsf-opinion-negative-reason-polemicalbut the opinion is unsubstantiated and stated in an unhelpful manner.

In addition to the tagging, which I hope others continue to do using this vocabulary, I took notes on each one, which I now present here. Many of the notes say, “fixed in JSF2: <code>” where <code> is a key in the following table.

viewParamsthe View Parameters feature
ezcompcomposite components
ajaxJSF2 standard Ajax support
faceletsJSF2 standard Facelets
compcompatJSF2 standard component compatibility measures
select*Select* now take Collection of POJO.
exceptionHandlingJSF2 pluggable exception handler, better error messages, ProjectStage.
resourceLoadingJSF2 standard resource loader
bookmarkableJSF2 standard bookmarkability
navigationJSF2 standard implicit navigation
systemEventsJSF2 standard System Events
annotationsJSF2 standard annotations for most stuff
prgJSF2 standard support for POST REDIRECT GET
noWebXmlOn EE6, you don't need a web.xml if you are ok with /facelets/* and *.xhtml as your JSF servlet mapping.
elJavaEE 6 standard EL method invocation
flashThe flash scope
viewScopeThe view scope
stateSavingJSF2 standard partial state saving

[2004-03-04] JCP Releases JavaServer Faces 1.0
- I read this entire thread and there are just as many pro JSF messages as anti-JSF ones. Of course, you chose to extract only the negative ones. 

Also, in the "Programmers So Far Underwhelmed by JSF" article, there was also positive and negative and you only extracted the negative. 

You missed this, "If you would have talked 30 years ago to people programming in assembler, not everyone was happy seeing C come up," he told "That's just evolution, putting layers on top of other layers, but it's our belief that with JSF we get a very powerful layer that makes things easier." 

"Krause expects JSF critics to quiet down in the next six to 12 months, when the first JSF-enabled Web applications start hitting the Web portals and sites. His product, W4T, will include JSF in the coming months, and expects other tool vendors to follow suit." 

This is exactly what has happened.

[2004-03-05] JSF: The Ultimate in Flexibility? Or Complexity?
Entirely outdated and somewhat polemical.

[2004-06-09] Improving JSF by Dumping JSP
We've done exactly that in JSF 2.0. JSP is a backwards compatibility layer only.

[2004-08-06] My JSF Experience
The threaded discussion has about 40% pro JSF comments, but you don't mention that.

[2004-09-20] Boycott JSF
Citing the bile blog? Come now! I love Hani, he's a rockstar programmer in my book, but the bile blog was always more about polemecism than content.

[2005-07-??] Gradebook Taming JSF 1.1
Mr Davis says, "For example, backing beans would do database queries when a getter hits a null value. In practice, that meant we couldn't really be sure when the queries were being done or to what purpose. Some DB queries were issued in the Apply Request Values phase, some in the Process Validations phase, and some in the Render Response phase. We'd unexpectedly display old data instead of freshening from the DB. Or we'd add a "rendered" check to a button and find that submits had stopped working." 

This is a misunderstanding of the JSF lifecycle. Hitting the database from a getter is never a good idea. In JSF1, you could use a PhaseListener to do this, in 2 you'd use a SystemEvent

[2006-01-20] JSF Burrito: More Complete List
"POST vs choosing proper HTTP verb (personal annoyance) Difficult to link directly to a specific page with specific content [especially the first page in an app]" 

Fixed in JSF2: viewParams 

Component writing is much more difficult than writing JSP tags (Rick Hightower convinced me of this at NFJS) 

Fixed in JSF2 

Small free component market (compared to Eclipse; probably side effect of #3) [or even delphi components] 

Fixed by 2008 

"What's the point of JAAS and all the other security advances made if we're advised to "throw them out"?" 

Who gave you that advice? I show a nice integration of JAAS and JSF in my JSF 1.2 book. Also, in JSF2, System Events work well for very fine graned role based access control. 

"Unit testing our pages is too difficult." 

JSFUnit works well here. 

"AJAX components are coming, but it's much more difficult to integrate it on your own." 

Fixed in JSF2: ajax 

"Templating seemed difficult to do with JSF" 

Fixed in JSF2 facelets. Also, Facelets has become the defacto standard for templating in JSF 1.x.

[2006-02-10] JavaServer Faces - why?
This is a largely fact-free polemical post. The comments have several well-reasoned favorable responses to JSF.

[2006-02-21] Usability problems in JSF
Thanks for including a post from our star expert group member Adam Winer. Adam was instrumental in bringing JSF to the level of success it currently has.

[2006-05-03] Where JSF and Portlets went wrong...
"(try using ICEFaces components with ADFFaces)" 

Fixed in JSF2: compcompat. This was a central focus of JSF2. We'll know it's fixed when all of the parties have released JSF2 versions of their libraries. 

"While third-party options (like Facelets) do make programming with JSF easier" 

Fixed in JSF2: facelets 

There were a number of positive aspects to this post but you chose to only extract the negative ones.

[2006-05-19] JavaOne: Google Web Toolkit vs. JSF
More than half of the comments on this blog entry are pro-JSF.

[2006-06-19] JSF Rough Spots
"selectItems tag is way too unflexible - it only takes a Map. You'd think you should be able to show a simple String array or a List of Strings, but no." 

Fixed in JSF2: select* 

"The EL should be able to, as in OGNL, create objects has it comes across the need to." 

This one I don't understand. The JSF EL has always done this. 

"Every JSF page must define and load its resource bundle. I'm probably getting this wrong, but AFAICT, this is required. If true, this seems redundant and inefficient." 

Fixed in JSF 1.2 (2007) 

"JSF exception messages weren't very helpful." 

Fixed in JSF2: exceptionHandling

[2006-09-08] JSF and RSFHistory
I note that RSF hasn't been updated since 13 September 2008 for its 0.7.4 release. Does anyone know if this is still an active project?

[2006-09-13] Geebis Blog: Wicket
"The biggest reason is that creating custom components in JSF can be difficult, especially if you want your components to have lots of javascript/css that it contributes to the page." 

This problem has been solved very well in JSF2. The combination of composite components and resources is a very powerful answer to this person's problem. Fixed in JSF2: resourceLoading 

Also, Ken Paulsen and Jason Lee wrote a nice article about how to do this in JSF 1.x at

[2006-09-16] Tinman and the Scarecrow
"In JSF, you cant copy-paste a url into a new browser and expect the same page to show up." 

Fixed in JSF2: bookmarkable. Also, the PrettyFaces JSF add on does this even better. 

"JSF has a rudimentary IoC container somewhat inspired by Spring; though nowhere near as powerful" 

Many sites have been using JSF and Spring in production for at least three years. Also, the IoC container in JSF was inspired by ATG Dynamo and in fact pre-dated Spring by a month or two in concept. 

The rational for this rudimentary IoC container built into JSF is to give a useful experience to JSF users that want to use straight tomcat. JSF + Tomcat was the lightest weight full stack IoC container when it came out in 2004. Much lighter weight than Spring at that time. 

Nowadays, you have many options here: CDI, Guice and of course Spring. 

"JSF uses absolute, declarative navigation enforced by lengthy XML, triggered by passing string-keys around--pretty piss poor design in this day and age and quite clearly a legacy of Struts." 

Fixed twelve ways to Sunday in JSF2: navigation 

"For some bizarre reason, JSF does not play well with the JSP errorPage directive." 

Fixed in JSF2: exceptionHandling. Not just that but there is a pluggable exception handler.

[2006-10-19] Faces: The emperor has no clothes
"Then the hell of linking pages together starts." 

Fixed in JSF2: navigation 

"Not trying to be sarcastic here, since Facelets is pretty good, but this complicates the hiring and education of the team and in fact invalidates the selling point of Faces 'being a standard'." 

Facelets is now the standard.Fixed in JSF2: facelets 

"The spec is heavily based on two things: POST params and (ugh) forward navigation rules, that are default. In my previous life forward was the exception, not the norm." 

POST is still the default, but it's much easier to do proper POST REDIRECT GET, or GET REDIRECT GET in JSF2.

[2006-12-15] Nightmares on JSF Street in Trinidad
This post has very little to do with core JSF and instead talks about the Trinidad JSF component library.

[2006-12-19] Reasons to choose Wicket over JSF and Spring MVC
"I liked its form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it." 

As Jason Lee said in the comments, all you need to do to not have JavaScript is avoid using h:commandLink. Now, with JSF2, you have the additional step of not using Ajax, because it's really hard to do Ajax without JavaScript (though I heard you can do Ajax with CSS and no JavaScript).

[2006-12-26] not enamored by JSF 1.1
I found this thread to be largely fact based. I think this is a great way to discuss APIs. Unfortunately, this discussion pertains to a version of the spec that is over five years old.

[2007-01-01] JSF in 2007
Here we can see the influence of Seam on people's opinions. Note that most of the good ideas in Seam went either into JSF2 or into CDI. 

In the TSS comments I see, "Above all I think the Java community need to get away from premature standardisation of APIs, and let time and experience decide." 

This has been my approach to developing JSF2 from the beginning, and I'm happy to see all the different ideas from many different sources in there.

[2007-01-18] Tech Talk: Ed Burns on JSF 1.2
"Make it trivial to design custom components. I am not saying make it easy. I am saying make it trivial." 

Composite components to the rescue. Fixed in JSF2: ezcomp 

"There is no "page load" event handler to do initialization." 

System events make this even more fine grained in JSF2. Fixed in JSF2: systemEvents 

As the author of this talk, I don't see how it supports your argument about JSF.

[2007-02-19] JSF is cool but it is too young and it has too many bugs!
We live in an age of super-heterogeneous development stacks. In this world it's very easy to run into situations where the various layers of the stack interact poorly. The author would have been well advised to check into one of the forums of the component libraries in the stack.

[2007-02-28] JSF Anti-Patterns and Pitfalls
Nice that you quoted Dennis Byrne's article. He was a leading light in the MyFaces development for JSF 1.2. 

Also, any technology has its collection of best practices and gotchas. The fact that those for JSF are so well documented shows its vitality. Let's take a look at Dennis's subsections. 

The Deja vu PhaseListener 

Fixed in JSF2: systemEvents 

XML Fetishism 

Fixed in JSF2: annotations. No XML is required. Not even web.xml. Annotations are available for everything according to the 80/20 rule. 

Thread safety 

These issues are inherent in distributed multi-user systems design. The same issues will arise for shared objects in any web framework that uses the Servlet infrastructure. 

Facelets Migration Challenge: Tags with Behavior 

Putting behavior in your tags has always been discouraged. Dennis is simply adding to that chorus. 

Law of Demeter 

This one has nothing to do with JSF specifically and is simply a best practice about EL. 

Code to Interface 

This one has even less to do with JSF or EL or web frameworks. It's simply an axiomatic truth: make as few assumptions as possible by depending as little as possible on specific contracts. In Java, that means using interfaces correctly. 

View state encryption 

Note that turning on view state encryption in JSF is as simple as setting a content-param. How do you do that in Wicket?

[2007-03-17] JSF - Still pretty much a steaming pile of donkey turd
The author clearly does not like frameworks where the UI is built declaritively with markup that stands in for anything. He prefers plain HTML. For him, Wicket may be better. Also, he mentions the error messages problem, which has been solved for years with facelets and now solved in the JSF2 standard. 

Comments have: 

"I would have thought minimum requirements for a web layer toolkit would include: 

- *not* being forward based, e.g. should support Post-Redirect-Get out of the box 

- *not* baking in view artifacts, like referencing JSP pages. Use logical view names and allow a view resolver to work out what view technology is being used. 

- Having a halfway decent notion of a conversation as well as rich *navigation*. " 

All of these are fixed in JSF2: prg, navigation.

[2007-04-16] JSF still sucks?
I wonder why you didn't extract this quote from Matt Raible, "IMO, Facelets is very easy to learn. " 

He also talks about "developer abandonment". Well, here we are now nearly three years later and there's more interest and development in JSF than ever. That's not very abandoned.

[2007-04-26] Creating a jsf div component
The article point out the steps that used to be required for building a custom UIComponent in JSF 1.2. None of these are required any more. A custom component can be just a single Facelet page.

[2007-05-14] A Wicket user tries JSF
"Wicket does not require any extra XML config like you have faces-config.xml for JSF" 

In JSF2, you don't need faces-config.xml. IF you're on EE6, you don't need web.xml either. Fixed in JSF2: noWebXml 

"Wicket does not require JSPs" 

JSF2 doesn't require JSPs either. Also, the .xhtml extension is automatically mapped to JSF. Fixed in JSF2: noWebXml 

"Navigation logic is performed in pure Java code which is much more..." 

JSF2 navigation can be done centrally or per-page but it's always declarative. JSF2: navigation

[2007-05-22] Rethinking JSF - The Real Problem
The discussion on this thread was too mammoth to review in my limited time. However, scanning through it, I see an even balance of pro-JSF and anti-JSF positions.

[2007-05-23] Six Things JSF Breaks (and How To Fix Them)
I like this post. It is exactly correct and none of the recommendtions he makes are onerous, except for the desire for completely standards compliant XHTML. For simple pages this is possible, but when you use advanced components it is hard to guarantee.


Back in November, Sebastian Hennebrueder published a detailed, thoughtful, and mostly objective analysis of JSF2. I'd like to use this entry to respond to his entry, which may be found at I have excerpted the parts of his article that pertain to my comments here.

JSF 2 - evaluation and test 



JSF is a standard to implement Java based web framework. There is a reference implementation of the standard, Mojarra JSF...



Add the following libraries to the build path of the web application.

  • jsf-api-2.0.0-SNAPSHOT.jar

  • jsf-impl-2.0.0-SNAPSHOT .jar

  • jstl 1.2

    edburns: Why do you need JSTL? That's only necessary if you're using JSP. This is a bug in the implementation and not the spec. 1517.

The deployment approach for JSF libraries is slightly picky. Glassfish provides already JSF 2 libraries. You may need to update them using the update mechanism of Glassfish. Just search for ?glassfish JSF2? to find more...



Modify the web.xml

The Servlet class FacesServlet starts the JSF request processing life cycle and must be defined in the web.xml. The servlet mapping tag defines the for which URL the FacesServlet should be executed. The pattern /faces/* is commonly used by the JSF specification but any other prefix or extension is possible. The example uses as web-app attribute version=?2.5? this means we are using servlet-api version 2.5. If you use tomcat 6 we need minimum servlet-api in version 2.5. Compared with jsf 1.2 nothing changed in this example.

edburns: If you are on Glassfish v3 final you don't even need a web.xml at all. The /faces/* and *.xhtml url-patterns are mapped by default to the FacesServlet. Also, if you're using Glassfish V3, please set the version to 3.0.

Below you can see the web.xml...


Technical details

The following diagram shows all places where events listener are called. The diagram is slightly simplified. The FacesServlet is the entry point of the JSF application. It calls the lifecycle, which in return executes the different phases. Every phase calls global phase event listener before and after the actual work is done. Sample: 3 and 4 in the RestoreView phase.

PhaseEvent listener can be defined per view as well. These listener are called by the root component, UIViewRoot. This happens in the diagram for example at 9 and 14.

FaceEvents (alias Application events) are broadcasted by the UIViewRoot component. This happens in every phase. Sample: 12, 21, 28, ?

edburns: This sequence diagram is excellent!

System events are broadcasted immediately at various points in JSF. Just search the source code for publishEvent...



The second problem of standardizing is that a standard is a compromise and it progresses very slowly. A compromise does not include very innovative or individual features and needs to ensure that it doesn't change vertically. Changing vertically means that it adds more responsibility as it had before. In JSF 1.x Ajax behaviour were not defined. Every component provider solved Ajax requirements differently and now JSF 2 introduces its own mechanism.

edburns: This mechanism was designed by the component vendors who built Ajax components for JSF 1.2. The point of the standard jsf.js file is that those vendors will be able to drop their proprietary JavasScript code and use the standard one, thus allowing component interoperability.

There is a fair chance that components...



JSF offers two types of components: composite components and the classic ones. Composite components are introduced with JSF 2. I would call it a snippet instead of component, which allows to render a number of components using a single custom tag. I think that it is a mistake to introduce a new component approach and to leave the old heavy components which have quite a number of contracts to follow.

edburns: As you point out, we are committed to backward compatibility and wanted to allow JSF 1.2 style components to work. More importantly, composite components build on top of the infrastructure of 1.2 style components.

Composite components are of course a great help...


edburns: Doch, every composite component has an optional "top level component" which can be in Java or in Groovy. This top level component is an actual JSF UIComponent and has access to all of its children component declared in the XHTML. Furthermore, it can override any of the UIComponent methods to take special action in the lifecycle.

Writing custom components is frequently... used to ensure a consistent look and feel in


large enterprise application. Modern frameworks like Google Web Toolkit (GWT), Tapestry or Wicket try to make this as simple as possible. As a consequence, it is a common and frequently task for developers using those technologies. In JSF writing of components is a job for experts only. In fact most people use only finished component collections and would never write a component themselves. In my opinion, this is one of the strongest weaknesses of JSF 1.x and it is not fixed with JSF 2 and as the JSF interest groups are mostly industry companies preferring backward compatibility over efficiency and innovation we won't even see it fixed in any JSF version. 


edburns: You depart here from your normally objective analysis to make opinions about the difficulty of building components in JSF2. Composite components ARE true JSF UI components. They have properties, methods, events, can support listeners, converters, validators and facets. They can be as simple as a single XHTML file, or as complex as to involve CSS, Script, and Ajax.


JSF introduces now a flash scope...



The validation can be ajaxified with the new<f:ajax> tag. Leaving an input field will validate the input for that field. An Ajax request is sent to the server, which causes a partial processing of the input element. This is much better than waiting for a form submit but could cause DOS attacks against the server.

edburns: This is true for any Ajax solution. This is not a fault of JSF. Any Ajax allows users to leave themselves open to this problem.

Just press the TAB-button, let the cursor jump from input field to input...


The integration of the Hibernate Validation framework (Bean Validation spec) looked liked a great improvement on the first view. You add annotations like @Size or @Length to a field of the managed bean or directly in an entity bean. This allows to use the same set of validation rules for Hibernate and for JSF. This is pretty nice and the integration works like a charm. The problem is actually not a problem of JSF but of Bean Validation. Somehow in the last moment, they changed the group validation to use class name instead of strings.

edburns: Ah yes, type safety is a knife that cuts both ways, isn't it?

Group validations are an important feature to...



To summarize, the lack of a DI container as core of the framework is a disadvantage of JSF. I assume that this is again a tribute to be backward compatible.

edburns: I'm quite sure that if JSF introduced its own DI container then you'd be saying something like, "this is yet another reason why JSF is bloated...". The fact is, the


JSF EG is not the DI EG. Different experts, different expertise. Also, separation of concerns is vitally important. Surely you know that innovation happens elsewhere. 


Future of web frameworks

I will add this section after the Devoxx conference end of November. It is an outlooked how component oriented frameworks could change....



There is no build in security but you will find examples how to integrate JSF with Spring Security.

edburns: What do you mean by that? We've had the ability to encrypt the view state since JSF 1.2. Security is a cross cutting concern that was baked into every design decision.

If you use JSF with JBoss Seam,...


Technorati Tags: edburns

Filter Blog

By date: