-
30. Re: ICEfaces
ssilvert Nov 27, 2006 9:35 PM (in response to gavin.king)"stan.silvert@jboss.com" wrote:
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 -
31. Re: ICEfaces
stu2 Nov 28, 2006 9:50 AM (in response to gavin.king)
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. -
32. Re: ICEfaces
gavin.king Nov 29, 2006 4:21 PM (in response to 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. -
33. Re: ICEfaces
evdelst Dec 4, 2006 9:02 AM (in response to gavin.king)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) -
34. Re: ICEfaces
pabreau Dec 6, 2006 12:11 AM (in response to gavin.king)Hi,
This can happen with the <ice:selectInputText> tag if you haven't declared the icefaces css:
Philip -
35. Re: ICEfaces
pabreau Dec 6, 2006 12:12 AM (in response to gavin.king)<link rel="stylesheet" type="text/css" href="./xmlhttp/css/xp/xp.css" />
-
36. Re: ICEfaces
evdelst Dec 11, 2006 4:48 PM (in response to gavin.king)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 -
37. Seam debug page with ICEfaces
markcollette Dec 15, 2006 5:10 PM (in response to gavin.king)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 -
38. Re: ICEfaces
tedgoddard Apr 24, 2007 1:16 PM (in response to gavin.king)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.