Community
Participate
Working Groups
1) Create a JSF project targeting a JEE5 server, but instead of taking the default 1.2 level, downgrade to 1.1. 2) Create a JSP 3) run it on server. PROBLEM: The URL for the browser is not re-written to use Faces Servlet mapping and thus the page will not render. JSFFileURL#getFileURL fetches a JSFUtils object based on JSF version (1.1 in this case) and web.xml model based on Web version (2.5 in this case). The problem is that web.xml model objects are different for different web levels, yet JSFUtils objects work only with "matching" web.xml's. That is, JSFUtils11#getFileUrlPath expects web.xml model 2.4 and does not handle anything else.
This is a regression from 3.1.2. It was introduced when JSFUtils were refactored in March of 2010. Prior to that, all web.xml access logic was handled by JSFFileURL#getFileURL itself, based on web level.
This is a major issue for users who import existing projects that were created for older servers and now try to run them on a newer server. The user can not change JSF facet version to a higher value (due to bug 201792) and thus is stuck with a broken "Run on Server" function. Can this please be considered for the next available maintenance release/patch opportunity?
Upon further look, this is a more general problem than just URL re-writting for Run On Server. The JSFUtil classes are now tightly coupled with a specific Web level and corresponding APIs. This will fail whenever JSFUtil classes are used in a project that uses non-default JSF/Web mapping (eg JSF 1.1 on JEE5). For example, in JSFFacet[Install/Uninstall]Delegate where web.xml is accessed for servlet and mapping configuration. The delegates get an instance of JSFUtil according to JSF level and then use it to modify web.xml, regardless of Web level. Although the delegates themselves check web level to be J2EE or JEE, they call JSFUtilXX.updateWebApp method in both cases. And JSFUtilXX.updateWebApp is setup to handle only one type of web.xml, depending on JSF version.
This issue occurs in the projects targeted for Tomcat6 or WAS7.
As you fix this defect, please also make sure JSF 1.2 works with web 3.0(i.e. WAS 80) app server, even though the default combination is JSF2.0 with web 3.0 (i.e. WAS 80)
Created attachment 172689 [details] patch
I've attached a patch that separates web.xml access from JSFUtils (into J2EEUtils and JEEUtils).
Thanks Yuri. I have been working on a fix for the past couple of days and was basically taking the same approach. As I have been testing mine, I will probably stick with that one. Can you please tell me if you were using MyFaces, and if that makes any difference to the behaviour you are seeing?
Thanks for working on a solution. There was no activity here, so I decided to tackle it myself. Feel free to throw mine away. :) I don't see how JSF implementation would matter here. There is nothing in the affected code that is implementation specific. Only JSF version and Web version matter. I'm using MyFaces for JEE6 and RI for JEE5/J2EE.
I have checked in your patch basically as is. My attempted fix was a little too ambitious and I ran out of time. I have tested all possible combinations of JSF and Web versions, and all seems well. I have not tested WAS runtime specifically.
Thanks!
The fix does not seem to be included in M-3.2.1-20100708210440 org.eclipse.jst.jsf.core is still at 1.3.0.v20100602 level. Is there a problem with versioning/tagging/packaging?
(In reply to comment #12) > The fix does not seem to be included in M-3.2.1-20100708210440 > org.eclipse.jst.jsf.core is still at 1.3.0.v20100602 level. > > Is there a problem with versioning/tagging/packaging? Investigating..
(In reply to comment #12) > The fix does not seem to be included in M-3.2.1-20100708210440 > org.eclipse.jst.jsf.core is still at 1.3.0.v20100602 level. > > Is there a problem with versioning/tagging/packaging? Per the map file, the latest build has the fix: http://build.eclipse.org/webtools/committers/wtp-R3.2.1-M/20100716070539/M-3.2.1-20100716070539/
Thanks. I was looking at the latest published at http://download.eclipse.org/webtools/downloads which is 0708 and was surprised not to see a fix made on 0630 in a 0708 build.
