ICESoft has announced the release of ICEFaces 1.7, their component suite for JSF. ICEFaces is built around the concept of a live DOM, such that changes on the server can be reflected on the JSF client, with only a bit of coding. The applications for this can be seen in any "live" application, like an auction site, where a new bid can be reflected on every client paying attention to a given auction (which is one of the demos included with the distribution), or a chat application of some sort. The new release, a free download after registration on icefaces.org, includes a lot of improvements: new components types, including components for Google Maps and a rich text editor, along with enhancements to the already-existing components. A new theme, "Rime," has been added to the "XP" and "Royale" themes. The component showcase illustrates the new components and themes fairly well, including how to use the components programmatically. AJAX push is still scalable in 1.7, thanks to out-of-the-box support for asynchronous request processing applications like Tomcat's and JBoss' NIO frameworks, as well as Glassfish' Grizzly framework. They've also corrected some issues with multiple viewports using asynchronous updates, caused by browsers' connection limits. ICEFaces 1.7 also has improved portlet support, improved documentation, new tool integrations, and new Seam sample applications. One thing that has not changed yet is the JSF 1.2 integration; ICEFaces requires 1.1-compatible DTDs to be used, which disables some of the nicer JSF 1.2 features like Java EE injection. (However, the use of Spring as a delegating resolver for JSF can provide many of the same benefits as Java EE injection for an ICEFaces application.) Good job on the update, ICESoft!

I'm curious to know why this wasn't included in the release. Quite possibly it's a lot more involved then I realize. Still, having to rely on Spring to workaround this seems unfortunate (if not already using Spring).

One thing that has not changed yet is the JSF 1.2 integration; ICEFaces requires 1.1-compatible DTDs to be used, which disables some of the nicer JSF 1.2 features like Java EE injection. (However, the use of Spring as a delegating resolver for JSF can provide many of the same benefits as Java EE injection for an ICEFaces application.)

I'm curious to know why this wasn't included in the release. Quite possibly it's a lot more involved then I realize. Still, having to rely on Spring to workaround this seems unfortunate (if not already using Spring).

Well, in their defense, it isn't trivial. I talk to some of the ICEFaces guys on a fairly regular basis; they said that JSF 1.2 isn't actually requested that often out of an annoying TSS editor, and it's scheduled for a later release. They're also pretty active on the JSF 2.0 EG, so chances are they'll support JSF 2.0 pretty soon after it's cooked.

As long as the web.xml is versioned at 2.5, resource injection should work no matter how the faces-config is versioned.

Congratulations to the IceSoft team! IceFaces is a great product and this release comes with a lot of features that we were expecting for a while.

Excellent. In light of the recent discussion "Java is losing the battle...", I want to say that this is exactly what the Java camp needs. Suites of modern components. Development with outdated request based frameworks (Struts, Spring MVC) is absolutely no alternative anymore. And the Seam integration is big plus. Thanks again.

...I don't necessarily like them either. But they are stable and widely understood. And there is nothing stopping people to create modern components on top of them. Also, by all means, JSF *is* an "outdated request based framework", just a lot *lot* more complicated than it needs to be. If you were rather thinking, software should mainly work using client side processing this begs the question why bother with the shortcomings of "Web 2.0" technology anyway and not build a proper gui in a proper programming language using a proper distribution mechanism.

The other thing is also unchanged: there are no client side events. Rich web UI that needs server round-trip to do ANY job (including ones that do not need it also) cannot be serious. We need: - date picker that has NO server round-trips (is that hard to write a JavaScript calendar?) - tab control where we can select which tabs are preloaded and opened w/o server round-trip - tree control where we can predefine which node children are preloaded and which are loaded on the request - grid where we predefine whether all data is loaded on page load (when sorting happens completely on client) or data is fetched page by page or couple of pages in advance. - etc. etc. in the same stile.

The other thing is also unchanged: there are no client side events. Rich web UI that needs server round-trip to do ANY job (including ones that do not need it also) cannot be serious.

+1. That is my biggest gripe with ICEfaces. Richfaces (http://www.jboss.org/jbossrichfaces/) has a better model - components can be refreshed three ways - 1) conventional full page refresh 2) ajax server based refresh 3) client side only refresh. However, ICEfaces has better set of components, at least the last time I checked.

..is still not available. This single issue is preventing us from using Icefaces though we like their component suite quite a bit. Lack of session replication prevents seamless fail-over of the application when the node that the client is connected to, goes down. Their forums state this will be in v2.0.

I tried to update the JSFMatrix.net, please feel free to comment issues, which are outdated, thx, Tom http://www.jsfmatrix.net