Using JSF in a project? Where does the time go? Blog
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
12 Comments
-
-
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. //
-
-
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
Cheers,
Cay
// -
-
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. //
-
-
-
ronaldtm Aug 3, 2010 12:15 AM