Bug 57802 - Compatibility with ICEfaces 1.8 over JSF 1.1 apps
Compatibility with ICEfaces 1.8 over JSF 1.1 apps
Status: RESOLVED FIXED
Product: Tomcat 8
Classification: Unclassified
Component: EL
8.0.21
PC All
: P2 regression (vote)
: ----
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2015-04-10 10:42 UTC by Patrick WENDJI
Modified: 2015-05-06 11:01 UTC (History)
0 users



Attachments
The way I modified the EL support(but i suggested a solution in the bug comment) (17.57 KB, text/plain)
2015-04-10 10:42 UTC, Patrick WENDJI
Details
ICEfaces 1.8.1 component showcase on Myfaces 1.1.5/Tomahawk 1.1.6 (31 bytes, text/plain)
2015-04-29 22:59 UTC, Patrick WENDJI
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick WENDJI 2015-04-10 10:42:35 UTC
Created attachment 32642 [details]
The way I modified the EL support(but i suggested a solution in the bug comment)

I noticed that some pages using boolean or String resulting EL expression which used to function well under Tomcat 7 and earlier versions of Tomcat 8.

The source of this is the use of ELContext in some methods of org.apache.el.lang.ELSupport. ELContext is used starting from JSF 1.2(unles I'm wrong, then feel free to notice it to me). Trying to use it with JSF 1.1 app results sometimes in null references giving NPE on the specified screens. To correct it, i commented the relevant blocks of code. What I might suggest is, for ascending compatibility, to use the following procedure:
-try to look for the value in ELContext
-if the result is null, then fallback to the older versions(e.g. Tomcat 7) ways of resolving EL values
Comment 1 Mark Thomas 2015-04-10 13:46:38 UTC
See the comment in the EL spec regarding backwards compatability.

Tomcaat has the org.apache.el.parser.COERCE_TO_ZERO configuration option (see http://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html#Expression_Language).
Comment 2 Patrick WENDJI 2015-04-11 15:27:10 UTC
I'm already using that option
Comment 3 Patrick WENDJI 2015-04-11 15:28:03 UTC
That's why i posted that bug
Comment 4 Patrick WENDJI 2015-04-11 15:31:36 UTC
Thé fact ils that i have NPE for even ont NULL expressions.
Comment 5 Christopher Schultz 2015-04-13 02:47:14 UTC
Care to post a JSP code sample that should work but doesn't? That would be the best thing to provide in a bug report such as this.
Comment 6 Patrick WENDJI 2015-04-15 09:39:08 UTC
(In reply to Christopher Schultz from comment #5)
> Care to post a JSP code sample that should work but doesn't? That would be
> the best thing to provide in a bug report such as this.

<ice:panelBorder id="page" styleClass="pnlBrdrDemo"
							style="width:100%" renderNorth="#{not uihome.showTitle}"
							renderSouth="#{false}" renderCenter="#{true}"
							renderWest="#{false}" renderEast="#{false}">

uihome refers to a not null JSF managed bean. The expression "not uihome.showTitle" gives a NPE.
Comment 7 Christopher Schultz 2015-04-15 12:53:23 UTC
Can you please paste a *complete* code example, including any JSP headers and JAR libraries that might be necessary to get that to compile and run?

Remember that not everybody is using your stack.
Comment 8 Patrick WENDJI 2015-04-16 11:01:41 UTC
(In reply to Christopher Schultz from comment #7)
> Can you please paste a *complete* code example, including any JSP headers
> and JAR libraries that might be necessary to get that to compile and run?
> 
> Remember that not everybody is using your stack.

Basically, I'm using JSP Xml syntax. My pages are using pure XML so basically no headers. For the librairies, there are ICEfaces 1.8.1, MyFaces 1.1.5 API and IMPL(and dependencies in apache commons), Spring 2.5.5, Hibernate 3.2.5, axis2 1.4.1, BIRT 3.2.7(embedded). The fact is the class and page are part of a very big project. That's why i'm extracting the problematic part.
Comment 9 Mark Thomas 2015-04-22 14:50:25 UTC
There is insufficient information in this report for a Tomcat developer to reproduce it. Please keep in mind that the Tomcat developers may have zero knowledge of JSF.

As Chris previously requested, a complete example needs to be provided. Whether this is a single JSP and a list of required libraries (my preference) or a zipped Maven project is a secondary issue. The primary issue is that a test case needs to be provide that will enable a Tomcat developer to build a web application that demonstrates this bug.
Comment 10 Mark Thomas 2015-04-28 20:39:47 UTC
Without a test case this is going to get resolved as INVALID.
Comment 11 Patrick WENDJI 2015-04-28 20:46:42 UTC
Sorry for the silence. I'm a bit busy right now since I'm building the test case part time. I'll come back to you once it's done.
Comment 12 Mark Thomas 2015-04-28 20:51:12 UTC
OK. No rush. We don't normally close things until there has been at least a month of inactivity. Worst case if this gets closed before you have a test case you can always re-open it when you have the test case.
Comment 13 Patrick WENDJI 2015-04-29 22:47:03 UTC
I have a test case but it's a 16MB WAR file. Can I upload it?
Comment 14 Patrick WENDJI 2015-04-29 22:59:16 UTC
Created attachment 32699 [details]
ICEfaces 1.8.1 component showcase on Myfaces 1.1.5/Tomahawk 1.1.6

The attachment works on Tomcat version 6.0.43 and 7.0.57 but not on 8.0.21
Comment 15 Patrick WENDJI 2015-04-29 23:00:56 UTC
I provided a uptobox link instead
Comment 16 Mark Thomas 2015-04-30 10:13:16 UTC
The download appears to require registration and/or payment.

I suggest you remove the JARs from WEB-INF/lib and replace them with a list of files and versions (assuming we can grab them from Maven central). That should bring the example under the BZ attachment limit. Alternatively, place the file somewhere that doesn't require payment or registration.
Comment 17 Patrick WENDJI 2015-04-30 18:17:47 UTC
Comment on attachment 32699 [details]
ICEfaces 1.8.1 component showcase on Myfaces 1.1.5/Tomahawk 1.1.6

http://dl.free.fr/fKFKRAwpc
Comment 18 Mark Thomas 2015-05-05 12:57:13 UTC
Thanks for the test case.

Your analysis was heading in the right direction but missed the real root cause. The problem was the incorrect default implementation of ELResolver.convertToType(). It failed to call context.setPropertyResolved(false). This meant older ELResolver implementations that inherited this method would return null and if ELContext.getPropertyResolved() was true, that null was treated as a valid conversion triggering the NPE.

This has been fixed in trunk and 8.0.x for 8.0.23 onwards.
Comment 19 Patrick WENDJI 2015-05-06 11:01:21 UTC
(In reply to Mark Thomas from comment #18)
> Thanks for the test case.
> 
> Your analysis was heading in the right direction but missed the real root
> cause. The problem was the incorrect default implementation of
> ELResolver.convertToType(). It failed to call
> context.setPropertyResolved(false). This meant older ELResolver
> implementations that inherited this method would return null and if
> ELContext.getPropertyResolved() was true, that null was treated as a valid
> conversion triggering the NPE.
> 
> This has been fixed in trunk and 8.0.x for 8.0.23 onwards.

I hope I helped. When will Tomcat 8.0.23 be released?