ICESoft has announced the release of the open-source ICEFaces 1.6.0, which bundles additional JSF components, tools to help integrate with JBoss Seam, compatibility with JSF 1.2 containers, compatibility with Opera, and support for the Liferay Portal. One of ICEFaces' core capabilities is the ability to initiate a change to a client-side DOM from the server; an example of this is the auction monitor demo, which updates information live while users make bids. They've also updated IDE support for Eclipse, Netbeans, and JDeveloper. ICEFaces integration consists of registering a set of servlets to handle JSF requests to provide ICEFaces capabilities (such as the ability to update a model on the client from the server side, as mentioned above) and the use of XHTML as opposed to HTML. The JSF 1.2 compatibility is not quite complete; it allows deployment into JSF 1.2 containers such as Glassfish, but requires the use of the JSF 1.1 deployment descriptor and an older web.xml descriptor, too, which serves to disable some of Java EE's core features (such as resource injection.) However, the ability to deploy into these containers is a big first step, and we should expect full 1.2 compatibility as the newer JSF specification becomes more common. JBoss Seam is supported with a custom version of SeamGen and other examples. ICEFaces is an excellent component set for JSF, with the ability to update data on a client as the server determines need and an excellent component set. Congratulations, guys.

The JSF 1.2 compatibility is not quite complete; it allows deployment into JSF 1.2 containers such as Glassfish, but requires the use of the JSF 1.1 deployment descriptor and an older web.xml descriptor, too, which serves to disable some of Java EE's core features (such as resource injection.) However, the ability to deploy into these containers is a big first step, and we should expect full 1.2 compatibility as the newer JSF specification becomes more common.

So, should I wait? I heard that ICEFaces doesn't compatible with Ajax4jsf. Is that true (i.e. we cannot use 2 in the same application)?

As I said on the Javalobby: Only Woodstock components are left. ;)

The JSF 1.2 compatibility is not quite complete; it allows deployment into JSF 1.2 containers such as Glassfish, but requires the use of the JSF 1.1 deployment descriptor and an older web.xml descriptor, too,

So, should I wait?

Probably not, but it depends which JSF 1.2 features you require (please add these requirements to the discussion). The current benefit is that you can use GlassFish and JBoss 4.2AS with the server-provided JSF implementation. Note that Facelets is still the recommended view definition technology for ICEfaces with JSF 1.2.

I heard that ICEFaces doesn't compatible with Ajax4jsf. Is that true (i.e. we cannot use 2 in the same application)?

This is not a tested configuration and incompatibilities have been observed in the past. ICEfaces and Ajax4JSF take very different approaches to page rendering and view definition so compatibility may be possible but is not likely trivial. Since one of the main benefits of ICEfaces is that update regions do not need to be specified by the designer, it is certainly important to ask why the two frameworks need to be combined.

Hi, if I create a portlet for Liferay using ICEFaces, Is the look & feel of the ICEFaces compoments the same of the Liferay portal ? If I change the look & feel of the portal, does change the look and feel of the ICEFaces components of my portlet? Can I use ICEFaces for creating portlets for other JSR-168 portals ? Is it tested in WebSphere Portal ? Thank you in advance Javier Paniza

Hi,

if I create a portlet for Liferay using ICEFaces,
Is the look & feel of the ICEFaces compoments the same of the Liferay portal ?
If I change the look & feel of the portal, does change the look and feel of the ICEFaces components of my portlet?

We're working closely with Liferay on this, but unfortunately look & feel is somewhat outside JSR-168 and needs to be handled in a portal-specific manner. Some styles are picked up automatically through CSS mechanisms, but some are not.

Can I use ICEFaces for creating portlets for other JSR-168 portals ?
Is it tested in WebSphere Portal ?

Thank you in advance
Javier Paniza

ICEfaces is not yet tested with WebSphere Portal, but we expect to support it in the future. Any feedback you can provide on using the current ICEfaces example portlets with WebSphere would be most welcome.

Ted & Steve: Congratulations to you and everyone at ICEsoft on this release. We at Liferay have enjoyed working with your engineers, and look forward to a bright future. Javier: In my work developing sample portlets for ICEfaces and Liferay, it has been my experience that many of the components like pickup the Liferay theme without a problem. In the case of components like , you'll want to specify the JSR-168 CSS class names in order to make sure that your messages pickup the current Liferay theme. For example: Other components like currently render themselves using the ICEfaces theme (XP, or Royale) rather than the current Liferay theme. Liferay is working closely with ICEsoft so that future releases of ICEfaces integrate more completely with Liferay themes. Regards, Neil

JSF 1.2 support only now, and still half baked!?? What the heck are these guys thinking? It's much more important to support latest version of a standard in timely manner, than to add some stupid zooming DHTML gimmicks. IMHO this also sends the signal that if we would commit to using ICEFaces we probably would not be able to upgrade to JSF 2.0 for 1-1.5 years after spec completion. /Henri Karapuu

What the heck are these guys thinking?

We were actually listening to our community, and delivering on the priorities established there.

...using ICEFaces we probably would not be able to upgrade to JSF 2.0 for 1-1.5 years after spec completion.

ICEsoft is actively involved in the JSF 2.0 expert group, so we will be well-positioned to deliver 2.0 capabilities as the specification matures, and the ICEfaces community demands. Steve Maryka CTO ICEsoft

What the heck are these guys thinking?

We were actually listening to our community, and delivering on the priorities established there.

...using ICEFaces we probably would not be able to upgrade to JSF 2.0 for 1-1.5 years after spec completion.

ICEsoft is actively involved in the JSF 2.0 expert group, so we will be well-positioned to deliver 2.0 capabilities as the specification matures, and the ICEfaces community demands.

Steve Maryka
CTO ICEsoft

As a follow up, ICEfaces has offered a very unique solution from day one from both a programming and end user experience standpoint. It's such a great example of thinking outside the box that JBoss has made commitments to enhancing integration with ICEfaces. Honestly, I'm very glad that Ted will be participating in the JSF 2.0 JSR.

As a follow up, ICEfaces has offered a very unique solution from day one from both a programming and end user experience standpoint.

Jacob, i'm not intimately familiar with ICEfaces, could you clarify what you mean by "unique solution"? To me ICEfaces seems to be just another AJAX JSF component library -- which is something that does not qualify as 'unique' these days [1]. [1] http://www.jsfmatrix.net/ /Henri Karapuu

As a follow up, ICEfaces has offered a very unique solution from day one from both a programming and end user experience standpoint.

Jacob, i'm not intimately familiar with ICEfaces, could you clarify what you mean by "unique solution"?

To me ICEfaces seems to be just another AJAX JSF component library -- which is something that does not qualify as 'unique' these days [1].

[1] http://www.jsfmatrix.net/

/Henri Karapuu

Mechanically, their rendering process with their components do comet-like behavior and take the extra step to handling partial rendering automatically-- not necessarily and the component level like ADF, AJAX4JSF, and DynaFaces, but within the *whole* rendering process which simplifies rich UI development even more for developers. Their component library is an added bonus really which only facilitates ICEfaces core feature set even more.

Has anyone seen any comparison matrix or just a report on what is the memory usage when using jsf components ? I looked hard everywhere on the net but all i got was complaints about how JSF and how it is a big memory hog. But no numbers. I did visit the icesoft website but nothing there either. I m consulting for a healthcare provider right now and planning to go into JSF heavily for the cust. service agent facing applications and then icesoft discussion came up to add some AJAX capability. But memory issue is scary. Any comments from anyone would be helpful !!

Has anyone seen any comparison matrix or just a report on what is the memory usage when using jsf components ?
I looked hard everywhere on the net but all i got was complaints about how JSF and how it is a big memory hog. But no numbers.
I did visit the icesoft website but nothing there either.

I m consulting for a healthcare provider right now and planning to go into JSF heavily for the cust. service agent facing applications and then icesoft discussion came up to add some AJAX capability. But memory issue is scary.

Any comments from anyone would be helpful !!

I don't think it would ever prevent you from going with JSF, just that it requires more hardware per user than going with a stateless action solution. Seriously, if you are writing a customer service app/internal where functionality is king, it'd be dumb not to go with JSF. In my experience, trying to coordinate sorting tables, complex forms, menus, etc-- things that are expected out of support applications vs. public sites, JSF is by far the clear winner. You are dealing with a more reasonable concurrent user base and JSF takes care of all of the state management and simplify complex interactions overall, making your job and other developer's jobs much easier.

This response isn't necessarily promoting JSF as the only solution here, just that with the deployment you're describing, it's much wiser to go with a feature-heavy framework over attempting to find what scales the best out of all other options out there.

Has anyone seen any comparison matrix or just a report on what is the memory usage when using jsf components ?
I looked hard everywhere on the net but all i got was complaints about how JSF and how it is a big memory hog. But no numbers.
I did visit the icesoft website but nothing there either.

I m consulting for a healthcare provider right now and planning to go into JSF heavily for the cust. service agent facing applications and then icesoft discussion came up to add some AJAX capability. But memory issue is scary.

Any comments from anyone would be helpful !!

I don't think it would ever prevent you from going with JSF, just that it requires more hardware per user than going with a stateless action solution. Seriously, if you are writing a customer service app/internal where functionality is king, it'd be dumb not to go with JSF. In my experience, trying to coordinate sorting tables, complex forms, menus, etc-- things that are expected out of support applications vs. public sites, JSF is by far the clear winner. You are dealing with a more reasonable concurrent user base and JSF takes care of all of the state management and simplify complex interactions overall, making your job and other developer's jobs much easier.

This response isn't necessarily promoting JSF as the only solution here, just that with the deployment you're describing, it's much wiser to go with a feature-heavy framework over attempting to find what scales the best out of all other options out there.

Thanks for the feedback. As you said we made the decision to go with jsf is soley based on complexity of the UI which a web based systems cannot manage. But the traffic is too high more than 200,000 representatives/users logged in at peak times. And even if I consider memory taken per user is 1 MB , our RAM requirements, Hardware requirements is looking ridiculous. So for a better infrastructure planning i want to produce correct numbers. and so was looking for some numbers to go by. It is surprising that there is hardly anything from big jsf players on jsf memory usage. Anyway .. i will look into some home grown profiling stuff to figure that out.

But the traffic is too high more than 200,000 representatives/users logged in at peak times. And even if I consider memory taken per user is 1 MB , our RAM requirements, Hardware requirements is looking ridiculous.
So for a better infrastructure planning i want to produce
correct numbers. and so was looking for some numbers to go by. It is surprising that there is hardly anything from big jsf players on jsf memory usage.

Anyway .. i will look into some home grown profiling stuff to figure that out.

Can't you just setup a cluster for this, so you aren't necessarily capped at all in your scalability from a webtier standpoint?

Can't you just setup a cluster for this, so you aren't necessarily capped at all in your scalability from a webtier standpoint?

200,000 simultaneous users would be impossible to support with Ajax Push without a cluster. Each push connection requires a socket, and there simply aren't 200,000 sockets available on a single machine. It would be necessary to run ICEfaces in "synchronous" mode (which is perfectly acceptable, many applications do not require Ajax Push). With regard to memory, ICEfaces with Facelets uses much less memory than ICEfaces with JSP (I don't know if Facelets applications generally use less memory than equivalent JSP applications, though).

Can't you just setup a cluster for this, so you aren't necessarily capped at all in your scalability from a webtier standpoint?

200,000 simultaneous users would be impossible to support with Ajax Push without a cluster. Each push connection requires a socket, and there simply aren't 200,000 sockets available on a single machine. It would be necessary to run ICEfaces in "synchronous" mode (which is perfectly acceptable, many applications do not require Ajax Push).

With regard to memory, ICEfaces with Facelets uses much less memory than ICEfaces with JSP (I don't know if Facelets applications generally use less memory than equivalent JSP applications, though).

Good to hear from you Ted. Thanks for the feedback. We will definately have clustering etc. we have about 40 solaris boxes 4 cpu each with 4 instances on each of them. i m just worried about RAM usage. how much RAM can i increase of existing hardware or do i need new one is a question. But as you said Facelets eat less memory than jsp with jsf. how do you say so? what numbers do you have to back them up? i m sure in theory you can prove it, but i cant decide how many machines just by assuming somehting in theory. a performance and memory matrix would have helped. Have a good friday .. i m going to get a cool beer...

But as you said Facelets eat less memory than jsp with jsf. how do you say so? what numbers do you have to back them up? i m sure in theory you can prove it, but i cant decide how many machines just by assuming somehting in theory.

We're working on obtaining some concrete numbers ... what we observe generally, however, is that when we configure ICEfaces demos with facelets (many of them can be configured either with JSP or Facelets since the syntax is equivalent for the functional parts of most pages) they can easily sustain the load on ICEfaces.org, but in JSP mode, the applications run out of heap space when the load peaks.

Mechanically, their rendering process with their components do comet-like behavior and take the extra step to handling partial rendering automatically-- not necessarily and the component level like ADF, AJAX4JSF, and DynaFaces, but within the *whole* rendering process which simplifies rich UI development even more for developers. Their component library is an added bonus really which only facilitates ICEfaces core feature set even more.

Interesting, thanks for the description. I was aware of server push support in ICEfaces, but didn't know about the differences in rendering. I'm currently fitting GWT to be used as JSF components, but i'v started to have doubts if the GWT approach is ultimately a good match with JSF. If i may ask, whats your prefered JSF AJAX solution for writing custom components? /Henri Karapuu

What the heck are these guys thinking?

We were actually listening to our community, and delivering on the priorities established there.

To tell the truth i had always thought ICEfaces as the leading ajax component solution, and was looking forward for using it in my next JSF gig. Perhaps thats why the news about "coming late to the game" in regards of JSF 1.2 came as a quite a shock to me. If indeed this was the priority your customers have set, then i apologize my hard words. Instead, i'll just say 'what the heck the ICEfaces customers were thinking' :) /Henri Karapuu

What the heck are these guys thinking?

We were actually listening to our community, and delivering on the priorities established there.

To tell the truth i had always thought ICEfaces as the leading ajax component solution, and was looking forward for using it in my next JSF gig. Perhaps thats why the news about "coming late to the game" in regards of JSF 1.2 came as a quite a shock to me.

If indeed this was the priority your customers have set, then i apologize my hard words. Instead, i'll just say 'what the heck the ICEfaces customers were thinking' :)

/Henri KarapuuIt was the customers. I remember ICESoft asking them; since 1.2 adoption is still a little behind the curve, it makes sense that the customers wanted working solutions rather than future stuff. (Plus, I've been in touch with Ted and Steve over issues like this, to the point where I think they're tired of me.)

To tell the truth i had always thought ICEfaces as the leading ajax component solution, and was looking forward for using it in my next JSF gig. Perhaps thats why the news about "coming late to the game" in regards of JSF 1.2 came as a quite a shock to me.

If indeed this was the priority your customers have set, then i apologize my hard words. Instead, i'll just say 'what the heck the ICEfaces customers were thinking' :)

/Henri Karapuu

Until recently, it was difficult to run JSF 1.2 outside of GlassFish (this is definitely changing now) and the requirement of JDK 1.5 is still a problem for some customers. Your enthusiasm for JSF 1.2 is inspiring, though, so what are some of the specific features in JSF 1.2 that people must be crazy to not be using?

Until recently, it was difficult to run JSF 1.2 outside of GlassFish

I'v been running JSF 1.2 nearly 2 years outside of GlassFish. But, generally speaking you have a valid point.

Your enthusiasm for JSF 1.2 is inspiring, though, so what are some of the specific features in JSF 1.2 that people must be crazy to not be using?

As you know the only big deal at spec level was the JSP/JSF alignment, and i assume this didn't affect majority of your customers (if you promoted facelets use etc.) However, the really critical things were at implementation level. For example RI 1.2 had server side state saving working reliably with non-linear navigation something like a year before MyFaces. If i would had been stuck to 1.1 spec it would had meant that: a) My app would run up to 10x slower (because of client side state saving), or b) My app would blow to pieces when using back button. Also, it is possible to turn this question around. You seem to imply that JSF 1.2 was not a big deal - and indeed there were not many new features. Therefore porting apps to 1.2 spec level has been generally really easy. Would it had been big effort for ICEfaces to support 1.2 much earlier? /Henri Karapuu

Would it had been big effort for ICEfaces to support 1.2 much earlier?

/Henri Karapuu

Not really, but the top priorities with customers have been integration with JBoss Seam, Portlets, and component features, so other work took precedence. What is somewhat difficult is simultaneously supporting JSF 1.1 and 1.2 from a single codebase.

Not really, but the top priorities with customers have been integration with JBoss Seam, Portlets, and component features, so other work took precedence.

Fair enough. And i do apologize for my too harsh wording - i'm still surprised, and can't say i personally agree with the choice, but at least i could had been polite. Sorry, /Henri Karapuu

As you know the only big deal at spec level was the JSP/JSF alignment, and i assume this didn't affect majority of your customers (if you promoted facelets use etc.)

However, the really critical things were at implementation level.

For example RI 1.2 had server side state saving working reliably with non-linear navigation something like a year before MyFaces. If i would had been stuck to 1.1 spec it would had meant that:
a) My app would run up to 10x slower (because of client side state saving), or
b) My app would blow to pieces when using back button.

A small correction, server side state history has been a long time in myfaces it was there even before 1.2 came out. It was introduced into myfaces shortly after myfaces went out of apache incubation. But the 1.1 RI was the first to implement it, I agree. Anyway speaking of myfaces, the 1.2 implementation will be out soon now, with soon I mean the next few days, so finally things come to a good end there as well.

A small correction, server side state history has been a long time in myfaces it was there even before 1.2 came out. It was introduced into myfaces shortly after myfaces went out of apache incubation.

Werner, just for the record, and to clarify that i was not trying to badmouth MyFaces, here are my experiences: When i was starting project A in autumn of 2005 MyFaces didn't support reliable back buttoning with server side state saving, according to test cases i run at that time. When i started project B, in spring of 2006, Myfaces seemed to support back buttoning in single window, but it did not work correctly with multiple windows/tabs. /Henri Karapuu

A small correction, server side state history has been a long time in myfaces it was there even before 1.2 came out. It was introduced into myfaces shortly after myfaces went out of apache incubation.

Werner, just for the record, and to clarify that i was not trying to badmouth MyFaces, here are my experiences:

When i was starting project A in autumn of 2005 MyFaces didn't support reliable back buttoning with server side state saving, according to test cases i run at that time.

When i started project B, in spring of 2006, Myfaces seemed to support back buttoning in single window,
but it did not work correctly with multiple windows/tabs.

/Henri Karapuu

Ah ok that explains a lot, no problem, point taken, for multi windowing tabs etc... you probably are right. Cheers Werner

Congrats to the ICE folks on their new release :-)