Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Advice please: JSF1.2 or JSF2  RSS feed

 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No so long ago I started getting familiar with jsf.

But when i have sufficient basic understanding of jsf I want to do a serious project. So I'm wondering in which of these two I should put my time and effort
JSF1.2 or JSF2?

JSF1.2
Pro: mature, lot of support, lot's of tools
cons: will maybe soon be replaced with JSF2

JSF2
Pro: probably soon become the standard
cons: not mature, not much support yet, not much tools yet (at least not in jboss tools)
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Go with JSF2. It's fun to work with, and it deals with a few of the major shortcomings of JSF1.2. Having said that, it really isn't that different, so your skills are very backwards compatible.

-Cameron McKenzie
 
Shasi Mitra
Ranch Hand
Posts: 101
Flex Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make sure you answer the following question before to go with jsf.

Do you want your application to be scalable or do you want to improve productivity?

If your appl expects high user load, think again before you go with JSF. JSF eats lot of memory and has performance issues of its own.

If you are clear with the above, go with JSF 2.0 as they say they have improved some of the performance issues which they found in JSF 1.x
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did I miss something here? I thought JSF2 was not released yet. At least it's not in the Maven repository. And as far as I know, the only container that supports it so far is GlassFish.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Did I miss something here? I thought JSF2 was not released yet. At least it's not in the Maven repository. And as far as I know, the only container that supports it so far is GlassFish.


There is a release candidate for download. I've download it and replaced jsf1.2 in jboss 5.1. And for now it's working fine in Eclipse. Only the jboss tools doesn't support it. So you have to manually add the jsf facets.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shasi Mitra wrote:Make sure you answer the following question before to go with jsf.

Do you want your application to be scalable or do you want to improve productivity?

If your appl expects high user load, think again before you go with JSF. JSF eats lot of memory and has performance issues of its own.

If you are clear with the above, go with JSF 2.0 as they say they have improved some of the performance issues which they found in JSF 1.x


What do you suggest for a high load app, except for spring? It's so hard to find the proper framework for your app and than we haven't even mentioned the persistent layer. Ejb3, Seam, WebBeans?? My head is already spinning...
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that's a case where you should Avoid Premature Optimization.

JSF is a good prototyping platform, if it's nothing else. Although it's not necessarily the optimal platform for a thousand-user app, it's a good place to get the general look-and-feel right in a fairly short amount of time. If nothing else, you could take advantage of Fred Brooks' advice to "Plan One to Throw Away".

One good think about JSF, however, it that it's not an either-or proposition. If most of the pages on your webapp see light usage, you can convert the heavy-usage ones to Struts or even raw JSPs and they'll play nice with the JSF stuff.

Spring+JPA is another good idea, for the same reason. I've switched entire persistence mechanisms with almost no program mods using JPA persistency wired with Spring.
 
Dennis Zandvliet
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:
One good think about JSF, however, it that it's not an either-or proposition. If most of the pages on your webapp see light usage, you can convert the heavy-usage ones to Struts or even raw JSPs and they'll play nice with the JSF stuff.


Just curiosity. How do you do that?
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just ignore JSF. Use the same URLs you'd use for the the JSPs, Servlets, etc. as you would if there was no JSF. The JSF managed objects are ordinary session, application and request-scope objects, so you can locate them and use them the same way you would in any non-JSF apps.

Of course, there are some restrictions. If you create the objects yourself (especially request-scope objects), you'll have to do your own property injections, since JSF uses the faces-config file(s) to do that in JSF. And, of course, the code in your objects should not attempt to access JSF system resources, since there's no FacesContext when a non-JSF request is being processed - if you try to acquire and use one, you'll get a NullPointerException. But that's not as bad as it sounds, since the "ideal" JSF backing bean contains no javax.faces imports at all.

I usually inject all the JSF services from external abstract service providers, since that not only make me relatively immune to JSF dependencies, it also makes it easier to do unit testing. Of course, the one "non-ideal" feature a lot of my beans have are JSF datamodel objects, but non-JSF code can safely ignore those. Providing you leave JSF some sort of hint if you modify wrapped data.

The point is, JSF is not some sort of Master Control Program that must contain iron control at all times. It's a framework that can be used where convenient, and safely bypassed when it's not.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!