You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Marcel Reutegger (JIRA)" <ji...@apache.org> on 2007/02/09 14:14:05 UTC
[jira] Created: (JCR-739) Predefined entity references are not
decoded in string literal
Predefined entity references are not decoded in string literal
--------------------------------------------------------------
Key: JCR-739
URL: https://issues.apache.org/jira/browse/JCR-739
Project: Jackrabbit
Issue Type: Bug
Components: query
Affects Versions: 1.2.1, 1.1.1, 1.1, 1.0.1, 1.0, 0.9
Reporter: Marcel Reutegger
Assigned To: Marcel Reutegger
Priority: Minor
Fix For: 1.3
The entity reference is interpreted as is but should be decoded before the query is executed.
Example:
//element(*, nt:base)[jcr:contains(., 'max&moritz')]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (JCR-739) Predefined entity references are not
decoded in string literal
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger reopened JCR-739:
----------------------------------
Hmm, you are right. According to the XPath 2.0 syntax there are no entity references needed in string literals:
http://www.w3.org/TR/xpath20/#prod-xpath-StringLiteral
Jackrabbit uses a XQuery parser because of the order by extension defined in JSR 170 and there you need to encode the ampersand.
http://www.w3.org/TR/xquery/#doc-xquery-StringLiteral
Seems like the XQuery is not really a super set of XPath, even though it claims to be an extension to XPath.
> Predefined entity references are not decoded in string literal
> --------------------------------------------------------------
>
> Key: JCR-739
> URL: https://issues.apache.org/jira/browse/JCR-739
> Project: Jackrabbit
> Issue Type: Bug
> Components: query
> Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1
> Reporter: Marcel Reutegger
> Assigned To: Marcel Reutegger
> Priority: Minor
> Fix For: 1.3
>
>
> The entity reference is interpreted as is but should be decoded before the query is executed.
> Example:
> //element(*, nt:base)[jcr:contains(., 'max&moritz')]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-739) Predefined entity references are not
decoded in string literal
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471986 ]
Julian Reschke commented on JCR-739:
------------------------------------
Oops.
I think JSR-170 is precise in that it's not an XQuery expression, but an XPath expression plus "orderby" extension. Thus we can't use a standard XQuery parser out of the box. Seems we need to hack it, or use an XPath parser and extract the orderby stuff before parsing.
> Predefined entity references are not decoded in string literal
> --------------------------------------------------------------
>
> Key: JCR-739
> URL: https://issues.apache.org/jira/browse/JCR-739
> Project: Jackrabbit
> Issue Type: Bug
> Components: query
> Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1
> Reporter: Marcel Reutegger
> Assigned To: Marcel Reutegger
> Priority: Minor
> Fix For: 1.3
>
>
> The entity reference is interpreted as is but should be decoded before the query is executed.
> Example:
> //element(*, nt:base)[jcr:contains(., 'max&moritz')]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-739) Predefined entity references are not
decoded in string literal
Posted by "Julian Reschke (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471730 ]
Julian Reschke commented on JCR-739:
------------------------------------
Is this on the level of the JCR API?
Why would we want to decode entity references here? Entity references need to be considered when the query string is represented in XML, but here...?
> Predefined entity references are not decoded in string literal
> --------------------------------------------------------------
>
> Key: JCR-739
> URL: https://issues.apache.org/jira/browse/JCR-739
> Project: Jackrabbit
> Issue Type: Bug
> Components: query
> Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1
> Reporter: Marcel Reutegger
> Assigned To: Marcel Reutegger
> Priority: Minor
> Fix For: 1.3
>
>
> The entity reference is interpreted as is but should be decoded before the query is executed.
> Example:
> //element(*, nt:base)[jcr:contains(., 'max&moritz')]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-739) Predefined entity references are not
decoded in string literal
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger resolved JCR-739.
----------------------------------
Resolution: Fixed
Fixed in revision: 505286
Thank you for reporting this issue.
> Predefined entity references are not decoded in string literal
> --------------------------------------------------------------
>
> Key: JCR-739
> URL: https://issues.apache.org/jira/browse/JCR-739
> Project: Jackrabbit
> Issue Type: Bug
> Components: query
> Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1
> Reporter: Marcel Reutegger
> Assigned To: Marcel Reutegger
> Priority: Minor
> Fix For: 1.3
>
>
> The entity reference is interpreted as is but should be decoded before the query is executed.
> Example:
> //element(*, nt:base)[jcr:contains(., 'max&moritz')]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-739) String literal must not interpret entity
references
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger updated JCR-739:
---------------------------------
Description:
The ampersand character in a string literal is interpreted as a start character for an entity reference. This is because Jackrabbit uses an XQuery parser where a string literal is slightly more constraint than in XPath.
Example:
//element(*, nt:base)[jcr:contains(., 'max&moritz')]
throws a parse exception. Instead the parser should simply recognize the ampersand as regular character.
was:
The entity reference is interpreted as is but should be decoded before the query is executed.
Example:
//element(*, nt:base)[jcr:contains(., 'max&moritz')]
Summary: String literal must not interpret entity references (was: Predefined entity references are not decoded in string literal)
Changed summary.
> String literal must not interpret entity references
> ---------------------------------------------------
>
> Key: JCR-739
> URL: https://issues.apache.org/jira/browse/JCR-739
> Project: Jackrabbit
> Issue Type: Bug
> Components: query
> Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1
> Reporter: Marcel Reutegger
> Assigned To: Marcel Reutegger
> Priority: Minor
> Fix For: 1.3
>
>
> The ampersand character in a string literal is interpreted as a start character for an entity reference. This is because Jackrabbit uses an XQuery parser where a string literal is slightly more constraint than in XPath.
> Example:
> //element(*, nt:base)[jcr:contains(., 'max&moritz')]
> throws a parse exception. Instead the parser should simply recognize the ampersand as regular character.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-739) String literal must not interpret entity
references
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marcel Reutegger resolved JCR-739.
----------------------------------
Resolution: Fixed
Changed the strip.xsl to special-case the StringLiteral token and ignore the entity references.
Also regenerated and committed the XPath.jjt file.
Fixed in revision: 506382
> String literal must not interpret entity references
> ---------------------------------------------------
>
> Key: JCR-739
> URL: https://issues.apache.org/jira/browse/JCR-739
> Project: Jackrabbit
> Issue Type: Bug
> Components: query
> Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1
> Reporter: Marcel Reutegger
> Assigned To: Marcel Reutegger
> Priority: Minor
> Fix For: 1.3
>
>
> The ampersand character in a string literal is interpreted as a start character for an entity reference. This is because Jackrabbit uses an XQuery parser where a string literal is slightly more constraint than in XPath.
> Example:
> //element(*, nt:base)[jcr:contains(., 'max&moritz')]
> throws a parse exception. Instead the parser should simply recognize the ampersand as regular character.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.