Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 316926

Summary:

JSFFileURL#getFileURL fails when JSF version does not match its default JEE version

Product:

[WebTools] Java Server Faces

Reporter:

Yury Kats <yurykats>

Component:

Core

Assignee:

Gerry Kessler <gerry.kessler>

Status:

RESOLVED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

jqian, raghunathan.srinivasan, wxwu

Version:

3.2

Flags:

gerry.kessler: iplog+

Target Milestone:

3.2.1

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
patch	none

Description Yury Kats

2010-06-15 11:20:07 EDT

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.

Comment 1 Yury Kats

2010-06-15 11:44:42 EDT

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.

Comment 2 Yury Kats

2010-06-16 13:59:48 EDT

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?

Comment 3 Yury Kats

2010-06-16 17:41:55 EDT

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.

Comment 4 Thomas Wu

2010-06-16 23:20:32 EDT

This issue occurs in the projects targeted for Tomcat6 or WAS7.

Comment 5 Jing Qian

2010-06-16 23:50:39 EDT

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)

Comment 6 Yury Kats

2010-06-24 16:52:36 EDT

Created attachment 172689 [details]
patch

Comment 7 Yury Kats

2010-06-24 16:53:24 EDT

I've attached a patch that separates web.xml access from JSFUtils (into J2EEUtils and JEEUtils).

Comment 8 Gerry Kessler

2010-06-24 16:57:33 EDT

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?

Comment 9 Yury Kats

2010-06-24 17:04:44 EDT

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.

Comment 10 Gerry Kessler

2010-06-30 15:56:22 EDT

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.

Comment 11 Yury Kats

2010-06-30 16:13:15 EDT

Thanks!

Comment 12 Yury Kats

2010-07-16 11:05:36 EDT

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?

Comment 13 Raghunathan Srinivasan

2010-07-16 13:09:32 EDT

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

Comment 14 Raghunathan Srinivasan

2010-07-16 13:39:17 EDT

(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/

Comment 15 Yury Kats

2010-07-16 13:47:57 EDT

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.