aspose file tools*
The moose likes JSF and the fly likes Inclusion of ICEfaces in Project is Shutting Down Facelet Processing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Inclusion of ICEfaces in Project is Shutting Down Facelet Processing" Watch "Inclusion of ICEfaces in Project is Shutting Down Facelet Processing" New topic
Author

Inclusion of ICEfaces in Project is Shutting Down Facelet Processing

Rs Carter
Greenhorn

Joined: Mar 02, 2012
Posts: 4
I am trying to construct a simple JSF web application on Tomcat 7 built with Mojarra 2.1.13 and ICEfaces 3.1.0. I have have a simple facelet page that worked fine before the addition of ICEfaces, but as soon as I add the jar files for ICEfaces its dependencies the facelet xhtml page seems as if it's no longer processed by Mojarra. In this case, what I end up seeing in the browser is the unmodified original xhtml page without any of the component tags processed.

Here is my simple facelet page source:


If I build and deploy the skeletal application containing this page without ICEfaces or it's jars so all I have in the deployed application's WEB-INF\lib folder are the jsf-api and jsf-impl jars, it runs fine, sending this to the browser:


As can be seen, the facelet was processed as it should have been. However, if I rebuild the application, changing nothing except that I now add the ICEfaces jars and dependencies to the war file, I now get this in the browser when I hit the url for my page:


Note that none of the JSF component tags in the page were processed. The most perplexing thing is that I know that the FacesServlet is still being invoked properly. I downloaded and the attached the source for the jsf-api jar, set a breakpoint in the FacesServlet service() method, and attached my debugger to Tomcat, and confirmed that when I hit the page URL the FacesServlet is still tiggered as it should be. So the FacesServlet is still being called, but it's just not actually processing the xhtml page.

The jars in the application include the following when deployed with ICEfaces:
activation-1.1.jar
commons-beanutils-1.8.0.jar
commons-logging-1.1.jar
FastInfoset-1.2.12.jar
icefaces-3.1.0.jar
icefaces-ace-3.1.0.jar
icefaces-compat-3.1.0.jar
icepush-3.1.0.jar
jsf-api-2.1.13.jar
jsf-impl-2.1.13.jar
jstl-1.1.2.jar
mail-1.4.1.jar
portlet-api-2.0.jar


I have also confirmed that nothing in the deployment process is causing this. Going into the Tomcat webapps directory, deleting all the jar files except for the jsf-api and jsf-impl jars which I need for JSF to work sans ICEfaces, and restarting Tomcat fixes the problem. I can then manually re-add the jars and restart Tomcat, and this causes the problem to return. So with no other changes whatsoever, simply adding the ICEfaces jars to the application is preventing JSF from running properly.

Any ideas what could possibly be going on here?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16250
    
  21

When JSF does not process, you are almost invariably experiencing one of the following:

A. Your URL request is not being routed to the FacesServlet because you didn't set up a mapping rule properly in the WEB-INF/web.xml resource.

or

B. You are confusing URL paths and resource paths and attempting to use a resource path as a URL. For example: "http://myserver/abc.xhtml" is wrong, since "abc.xhtml" is the resource name. The correct URL would be "http://myserver.abc.jsf" for the most common JSF mapping configuration. The FacesServlet would then deconstruct that URL to create the internal "abc.xhtml" resource reference. Using "abc.xhtml" instead of "abc.jsf" as the URL would typically put you in violation of case A.


Customer surveys are for companies who didn't pay proper attention to begin with.
Rs Carter
Greenhorn

Joined: Mar 02, 2012
Posts: 4
Thanks for the input. However, these were also my first thoughts and I had already eliminated both of these as possibilities. I know for a fact that I'm hitting the correct URL and have the FacesServlet configured properly because when I hit the exact same URL without the Icefaces jars deployed, the facelet is processed as it should be. Also, I've confirmed that even with the extra jars that the FacesServlet is still being invoked by starting a debugging session and placing a breakpoint in FacesServlet.service(....). When doing this, the breakpoint is triggered, so we know that FacesServlet is definitely being called, yet it is still failing to actually process the xhtml page and returns the raw page as seen above if the ICEfaces jars are deployed.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Inclusion of ICEfaces in Project is Shutting Down Facelet Processing