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
Note that it's not just in the tag rule that we need to check the namespace, but in every rule that is applicable to the tag. For a typical <ice:> component, these would include also the tag object create rule, the set properties rule and the tag wire object create rule. Otherwise, extraneous objects would be left on the parse stack, messing up the build-up of the component tree; or, a rule may try to access a wrong or non-existent object on the parse stack due to a previous object create rule being skipped.
Mark has since found the "bug" in the commons digester method: org.apache.commons.digester.RulesBase#lookup. It's much cleaner to fix this bug than to check the namespace in every rule. To do this, we have to create our own RulesBase class to override the lookup() method, and use this new RulesBase class in our digester class com.icesoft.faces.webapp.parser.JsfJspDigester.