[ssilvert]

Another trick is to refer to these root-level jars inside <java> tags in the application.xml. There is some debate over which is the best/most portable way to do it.

This should say:

Another trick is to refer to these root-level jars inside java tags in the application.xml.

<java>icefaces-api.jar</java>

There is some debate over which is the best/most portable way to do it.

Stan

[stu2]

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.)

While it's definitely confusing sometimes, the parent/child classloaders for Ear/War is a "feature." For instance it lets you enforce separation of concerns, keeping presentation classes out of business logic. Seam's an interesting beast in this respect though, since presentation logic generally lives in EJBs.

I think libraries like IceFaces should support a variety of project structures. It should be possible to create a project jar containing business logic that may well return IceFaces data structures, but can't see servlet-specific view classes. I like the idea of having two jars. One that contains the data structures and anything else business logic might need to see, and another that contains everything else. You could take the Spring approach of providing one jar with everything, and alternately a set of finer grained jars that teams which want to carefully manage dependencies can use.

[gavin.king]

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.)

There are probably various ways to solve this problem, presumably you can do it by attaching more jars to the EAR classloader. (Obviously the JBossWebClassLoader was another solution.) I think the problem was really that I moved icefaces to the EAR classloader, but not facelets, and you were trying to load facelets from ICEfaces. Might have worked by moving facelets to the EAR classloader as well. I'm not an expert on this stuff. Anyway, its nonurgent, I just moved icefaces back to the WAR classloader.

You are definitely allowed to return non-primitive types from EJBs.

[evdelst]

Hi,
I also posted this on the icefaces.org forum, but maybe someone watching this thread can help.

I have been struggling for a couple of days to get the auto-complete functionality working with Seam.
However, the popup with possible values never appears.
If I look (with Ctrl+shift+T), I see the possible values in the response within div tags.

Am I trying something that wil not work with the current version? (Please let me know, so I can stop trying)

[pabreau]

Hi,

This can happen with the <ice:selectInputText> tag if you haven't declared the icefaces css:



Philip

[pabreau]

<link rel="stylesheet" type="text/css" href="./xmlhttp/css/xp/xp.css" />

[evdelst]

Bit late, but just to let you know: the CSS link helped.
I did have a link, in a facelet template, but somehow I messed it up.

Still have some other problems.
Some exceptions also mentioned in another post (also occurs with booking example), and some transitions in my pageflow stopped working, but I will investigate that later.

Edwin

[markcollette]

Sorry if this is a bit of cross-posting, but I was recommended to mention in this thread an issue for which I've already created another thread.

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994352#3994352

[tedgoddard]

As of ICEfaces 1.6.0 DR#3, substantial progress has been made with Seam/ICEfaces integration. In general, it is enough to simply add the ICEfaces .jar files to turn your Seam application into an Ajax application. Please download the latest ICEfaces release here:

http://icefaces.org/main/downloads/os-downloads.iface

Of particular interest are Ajax Push and seam-gen. ICEfaces Ajax Push is now working with Seam applications (this allows you to update the browser page under application control; no interaction from the user is required). To generate an ICEfaces application with seam-gen, please download the recently added ICEfaces seam-gen bundle

http://icefaces.org/main/downloads/project-downloads.iface

and unzip it at the root of your Seam 1.2.1 installation. You will then be able to generate ICEfaces Seam applications from within the icefaces-seam-gen directory. Over time we will be enhancing these templates to take full advantage of ICEfaces, allowing you to automatically generate a full CRUD application with a single-page Ajax user interface.