JBossDeveloper

Does anyone know about the behaviour of ICEfaces in a clustered environment?
From what I read, the Enterprise Edition work well in cluster. Now it seems to me that the Community Edition does too (but since their sale speech is based on the cluster support for the Enterprise version, they are not really detailled about what works or not in the free edition).
So looking on their forum, I read that the community edition supports clustered environments but doesn't scale as well as the Enterprise edition.

If anyone as any information, I'll be happy to hear it.

Richard

"rlhr" wrote:
Does anyone know about the behaviour of ICEfaces in a clustered environment?

Newbie question here: How is it that ICEfaces is compatible with Seam? Seam has its own listener. ICEfaces config would have me replace the seam listener with an ifaces listener. How does all the Seam glue code get executed?

I made a mistake when I said "listener". I noticed in the booking app that was ported to use ICEfaces that the web.xml file has the following commented out:

<!--
 <filter>
 <filter-name>Seam Redirect Filter</filter-name>
 <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
 </filter>

 <filter-mapping>
 <filter-name>Seam Redirect Filter</filter-name>
 <url-pattern>*.seam</url-pattern>
 </filter-mapping>
-->

Because ICEfaces makes use of two servlets, one for the initial page request and another for the Ajax requests, the interaction with Servlet filters is complex. For instance, an extension mapping is meaningless for the Ajax requests.

For this reason, we call the Seam filters directly from ICEfaces (so, to avoid calling them twice in some circumstances, they are commented out in the web.xml).

Eventually, the two ICEfaces servlets will be merged into one entry point and we will look at the interaction with filters more closely; however, we are happy to directly integrate with Seam at this time. (Two separate classes will remain for what is now two separate servlets, as the functionality of the two is very different; our plan is just to reduce the amount of configuration necessary.)

Could I use ICEFaces together with Ajax4jsf and together with Seam??

I already have Ajax4jsf, Seam, facelets and tomahawk in my project. I was wondering if I could integrate ICEFaces...

thanks,
Carlos Zaniolo

ICEfaces and Ajax4jsf are not currently runtime compatible, however we are making preparations to incorporate the tomahawk components into ICEfaces. Are there specific components that you would like to see first?

Hi Ted,

It is really a good news that you are making preparations to incorporate the tomahawk components into ICEfaces. In fact, if adding some very useful tomahawk components into ICEfaces, ICEfaces will be much powerful and beautiful. I don't think there are needs to integrate other JSF framework into projects. Based on my opinions, the specific components I like see are dataList, dojo, splitPane, accordionPanel, dynamicImage. In the future, if possible, the schedule is also very good. Thank you very much.

I am looking for some kind of generic highlight editor that works with Icefaces... much like t:inputHtml, but my needs are for Groovy and JPAQL/HQL code (I use this for customization on line of queries/reports).

A specific component that I would like is a generic editor.... at least customizable HTML WYSIWYG for highlight...

Thanks,

I found that the dojo wiki editor is very good, and tomahawk already integrate it. The dojo wiki editor was donated by Jotspot which already was bought by Google. I guess the dojo wiki editor will become more popular in the future.

ICEfaces 1.5.1 is now available from icefaces.org. Seam compatibility is substantially improved, particularly with the icefaces variant of the booking application.

Do you know if the classloader issue with the tree component is resolved in this release?

http://www.icefaces.org/JForum/posts/list/2919.page

The tree classloader issue is not resolved with ICEfaces 1.5.1, but it may be more of a configuration problem than an integration problem between Seam and ICEfaces.

Fundamentally the problem appears to arise because the EJBs and the web application are loaded by different classloaders. If an EJB returns and ICEfaces-specific type, it may have the same class name, but will be a different class than ICEfaces expects (as running in the web application).

So, is it generally a bad idea to return anything but primitive types from EJBs? Is there a simple way to configure the .ear so that the ClassLoaders are common? Should icefaces be split into icefaces-api.jar and icefaces-impl.jar? (In other words, we're looking for suggestions on how to best resolve this.)

"TedGoddard" wrote:
So, is it generally a bad idea to return anything but primitive types from EJBs?

"TedGoddard" wrote:
Is there a simple way to configure the .ear so that the ClassLoaders are common?