anonymous wrote : | 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989339#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...