I'm organizing my thoughts for my JavaOne talk HyperproductiveJSF 2.0 and I want to build the talk around the most common waysthat time is wasted when using JSF in a project. I've talked to lots ofusers, in many different kinds of organizations over the years but it'shard to organize the stories. So, I'm coming, cap in hand, to theblogosphere asking people to share the things that have caused them towaste development time when using JSF in production.

Here's a list to get you started. Please share things that havesimply taken too long to do when developing with JSF. You don't need tosay why it took too long, or how you worked around it.

  • Deployment step is slow

  • Server startup/shutdown slow

  • Have to restart the server too frequently

  • Complex server environment

  • Build is compiling/packaging things that haven't changed

  • Runtime library version mismatches

  • I have to get resources from all over the place in order to just build the war.

  • Getting all the necessary elements of the distributed system up and running takes too long.

  • I'm not getting the most out of my tools. They should be providing me shortcuts, but they are not.

  • Because there are so many different ways to do the same thing in JSF, we waste a lot of time trying to reconcile the different ways in different parts of the project.

  • We don't make use of continuous integration tools, so the builds are occasionally corrupt.

Anything else?

Technorati Tags:edburns


  • ronaldtm Newbie
    The last time we tried JSF (1.2), we wasted too much time trying to understand errors. The error messages, when they weren't swallowed, didn't help at all. For example, a "invalid value" was printed on the page, and nothing on the console. It turned out that what was causing this was a dropdown that expected SelectItem's and was receiving a list of strings. This kind of thing, mixed with Seam errors, turned our experience into a real nightmare. //
    • mwessendorf Newbie
    • bigallan Newbie
      Because there are so many different ways to do the same thing in JSF, we waste a lot of time trying to reconcile the different ways in different parts of the project. It took me ages to figure out the best/right way to use JSF. The net is flooded with tutorials on doing basic stuff with JSF, but few of them address concerns on how to build production-ready JSF applications. Another major annoyance in the beginner was the lack of proper support for HTML tables. Not being able to span across columns use to drive me crazy. //
      • pjmlp Newbie
      • cayhorstmann-3071947 Master

        A few points to add to your list: (1) Unit testing (2) Lack of an "app framework"--basic functionality such as authentication or menuing has to be rewritten each time (3) Painful I18n (programmatic access to resources, managing app messages vs. component messages vs. bean validation, resources other than strings) (4) Dealing with the Stack Trace from Hell



        • roguexz Newbie
        • kamalasekarr Newbie
          Most of my time is spent around deploying the application in server. I have my own build script that packages the war file (runs pretty faster). After few deployments in WASCE, we get OutOfMemoryError  although I set the JAVA_OPTS. I guess it reloads not only the context but also the dependent modules (by that time, the previous footprint should have been completely removed). I have tried integrating it with Eclipse IDE and publishing the app (the app server -plugin is quite effective that it detects the changes as soon as you modify the files); publishing it through.. Now, I still need to restart server but not that often. //
          • healeyb Newbie
          • rexcardan Newbie
          • vammpiro Newbie