Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.7.1
-
Fix Version/s: 1.7.2
-
Component/s: ICE-Components
-
Labels:None
-
Environment:JSP
Description
When ICE-2995 was being worked on, we ran into a JSP parser bug. This was when our component tags were <ice:html>, <ice:head>, <ice:body>. They're now called <ice:outputHtml>, <ice:outputHead>, <ice:outputBody>, to work around this issue. So, to duplicate this issue, you have to change the ICEfaces tags back to <ice:html>, <ice:head>, <ice:body>. Note that with JSF 2.0 and th upcoming <h:html>, <h:head>, <h:body>, this will be a problem again.
The problem is that when you have, for example a <html> tag in your JSPX page, the Digester Rules that we create in com.icesoft.faces.webapp.parser.ComponentRuleSet.addRuleInstances(Digester) will match on both the XhtmlTagRule to create a UIXhtmlComponent, and also any TagRule(s) to create any JSF components in any namespace, where their tag name ("html") matches the xhtml tag name that was parsed ("html"). So, in our case it would also wire up a TagWire for an <ice:html> tag, and in the JSF 2.0 case, another for the <h:html>. It's because Digester sees a null or empty String parsed namespace as a wildcard, that will match against any namespace.
This is not an issue the other way around. If the <ice:html> tag is parsed in the JSPX file, then that will not match with the XhtmlTagRule, and so will not also make a UIXhtmlComponent.
For backwards compatibility, we can't just make everyone set xmlns="http://www.w3.org/1999/xhtml" in their JSPX files, to give the parsed <html> tag a non-empty namespace.
In BaseRule and TagRule, it's possible to compare the Rule's namespace ( org.apache.commons.digester.Rule.getNamespaceURI() ) against the parsed one that is passed in as an argument to its methods, and act upon the difference.
The problem is that when you have, for example a <html> tag in your JSPX page, the Digester Rules that we create in com.icesoft.faces.webapp.parser.ComponentRuleSet.addRuleInstances(Digester) will match on both the XhtmlTagRule to create a UIXhtmlComponent, and also any TagRule(s) to create any JSF components in any namespace, where their tag name ("html") matches the xhtml tag name that was parsed ("html"). So, in our case it would also wire up a TagWire for an <ice:html> tag, and in the JSF 2.0 case, another for the <h:html>. It's because Digester sees a null or empty String parsed namespace as a wildcard, that will match against any namespace.
This is not an issue the other way around. If the <ice:html> tag is parsed in the JSPX file, then that will not match with the XhtmlTagRule, and so will not also make a UIXhtmlComponent.
For backwards compatibility, we can't just make everyone set xmlns="http://www.w3.org/1999/xhtml" in their JSPX files, to give the parsed <html> tag a non-empty namespace.
In BaseRule and TagRule, it's possible to compare the Rule's namespace ( org.apache.commons.digester.Rule.getNamespaceURI() ) against the parsed one that is passed in as an argument to its methods, and act upon the difference.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 1.7.2 [ 10130 ] |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 1.7.2RC1 [ 10140 ] | |
| Fix Version/s | 1.7.2 [ 10130 ] |
| Fix Version/s | 1.7.2 [ 10130 ] | |
| Fix Version/s | 1.7.2RC1 [ 10140 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |