| Summary: | Compatibility with ICEfaces 1.8 over JSF 1.1 apps | ||
|---|---|---|---|
| Product: | Tomcat 8 | Reporter: | Patrick WENDJI <wlpa2008> |
| Component: | EL | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | regression | ||
| Priority: | P2 | ||
| Version: | 8.0.21 | ||
| Target Milestone: | ---- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Attachments: |
The way I modified the EL support(but i suggested a solution in the bug comment)
ICEfaces 1.8.1 component showcase on Myfaces 1.1.5/Tomahawk 1.1.6 |
||
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). I'm already using that option That's why i posted that bug Thé fact ils that i have NPE for even ont NULL expressions. 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. (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. 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. (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. 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. Without a test case this is going to get resolved as INVALID. 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. 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. I have a test case but it's a 16MB WAR file. Can I upload it? 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
I provided a uptobox link instead 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 on attachment 32699 [details] ICEfaces 1.8.1 component showcase on Myfaces 1.1.5/Tomahawk 1.1.6 http://dl.free.fr/fKFKRAwpc 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. (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? |
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