[jira] [Created] (XALANJ-2747) xalan-j xpath3 function calls, should allow literal sequence and array arguments
Mukul Gandhi created XALANJ-2747:
Summary: xalan-j xpath3 function calls, should allow literal
sequence and array arguments
Key: XALANJ-2747
URL: https://issues.apache.org/jira/browse/XALANJ-2747
Project: XalanJ2
Issue Type: Task
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: Xalan-interpretive, XPath, XPath-function
Reporter: Mukul Gandhi
Assignee: Mukul Gandhi
It think, that it'll be useful to enhance XPath 3.1 function call invocations,
to allow literal sequence constructor and array expressions, as also suggested
within few examples within XPath 3.1 F spec as follows:
fn:for-each(("john", "jane"), function($x) { fn:string-to-codepoints($x) })
// this is slight variation from the example provided in XPath 3.1 F spec
spec. But this example is a correct XPath 3.1 function call.
array:for-each-pair(["A", "B", "C"], [1, 2, 3], function($x, $y) { array {$x,
$y}})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Assigned] (XALANJ-2746) NullPointerException on use of arrow operator (1 to 5) => sum()
[
https://issues.apache.org/jira/browse/XALANJ-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi reassigned XALANJ-2746:
Assignee: Mukul Gandhi
> NullPointerException on use of arrow operator (1 to 5) => sum()
> ---
>
> Key: XALANJ-2746
> URL: https://issues.apache.org/jira/browse/XALANJ-2746
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan, Xalan-CmdLine
>Reporter: Martin Honnen
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: arrow-operator-test1.xsl
>
>
> This is a bug report on the XSLT 3 development branch of Xalan.
> I see that the arrow operator => has been implemented but I have written a
> simple test case that gives a NullPointerException:
> Sample XSLT (run against any XML input):
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> exclude-result-prefixes="xs">
>
>
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
> {code}
>
> gives an error java.lang.NullPointerException
> {noformat}
> file:///C:/Users/marti/IdeaProjects/xalan-java/../../OneDrive/Documents/xslt/blog-xslt-3-by-example/xalan-xslt3-tests/arrow-operator-test1.xsl;
> Zeilennummer10; Spaltennummer51; java.lang.NullPointerException{noformat}
> Expected result would be `15`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2742) xpath3.1 map and array function implementations
[ https://issues.apache.org/jira/browse/XALANJ-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853073#comment-17853073 ] Mukul Gandhi commented on XALANJ-2742: -- I find the semantics of xpath3.1 map:find function, as described within the spec little hard to understand. I'll most likely not implement this function unless anyone on this list can further clarify, semantics of map:find function. Anyone wishing to contribute to further XSL3 development within xalanj, shall be most welcome. > xpath3.1 map and array function implementations > --- > > Key: XALANJ-2742 > URL: https://issues.apache.org/jira/browse/XALANJ-2742 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi > Priority: Major > > I'm creating this jira issue to track implementation of xpath3.1 map and > array functions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANJ-2742) xpath3.1 map and array function implementations
[ https://issues.apache.org/jira/browse/XALANJ-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851264#comment-17851264 ] Mukul Gandhi edited comment on XALANJ-2742 at 6/7/24 5:53 AM: -- Xalan-J's dev repos branch xalan-j_xslt3.0, currently has following completed map (associated with xpath namespace, http://www.w3.org/2005/xpath-functions/map) and array (associated with xpath namespace, http://www.w3.org/2005/xpath-functions/array) function implementations. XPath map, functions : merge, size, keys, contains, get, put, entry, remove, for-each XPath array, functions : size, get, put, append, subarray, remove, insert-before, head, tail, reverse, join, for-each, filter, for-each-pair was (Author: mukul_gandhi): Xalan-J's dev repos branch xalan-j_xslt3.0, currently has following map and array function implementations, Map functions : size, keys, contains, get, put, entry, remove, for-each Array functions : size, get, put, append, subarray, remove, insert-before, head, tail, reverse, join, for-each, filter, for-each-pair > xpath3.1 map and array function implementations > --- > > Key: XALANJ-2742 > URL: https://issues.apache.org/jira/browse/XALANJ-2742 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi > Priority: Major > > I'm creating this jira issue to track implementation of xpath3.1 map and > array functions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANJ-2746) NullPointerException on use of arrow operator (1 to 5) => sum()
[
https://issues.apache.org/jira/browse/XALANJ-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853020#comment-17853020
]
Mukul Gandhi edited comment on XALANJ-2746 at 6/7/24 5:33 AM:
--
[~martin.honnen], you're right. This is a defect.
.
In-fact, Xalan-J's xsl3 implementation currently has limitation, where literal
sequence constructor expressions can be successfully parsed and shall function
correctly, only when they form an entire XPath expression. i.e, an XPath
expression (1,2,3) shall work fine with Xalan-J currently.
But Xalan-J currently cannot handle,
for e.g, ... (1,2,3) OR (1,2,3) ...
(i.e, when an xpath sequence constructor is preceded or followed by any valid
tokens)
As a little workaround, your example shall work fine if we make use of XSL
variables, for e.g as follows,
For kind information, for few other Xalan-J xpath expressions as well, for e.g
literal non-empty sequence constructors shall not work fine as function
arguments (but we can use xsl:variable as workaround, for them).
was (Author: mukul_gandhi):
[~martin.honnen], you're right. This is a defect.
.
In-fact, Xalan-J's xsl3 implementation currently has limitation, where literal
sequence constructor expressions can be successfully parsed and shall function
correctly, only when they form an entire XPath expression. i.e, (1,2,3) shall
work fine with Xalan-J currently.
But Xalan-J currently cannot handle,
for e.g, ... (1,2,3) OR (1,2,3) ...
(i.e, when an xpath sequence constructor is preceded or followed by any valid
tokens)
As a little workaround, your example shall work fine if we make use of XSL
variables, for e.g as follows,
For kind information, for few other Xalan-J xpath expressions as well, for e.g
literal non-empty sequence constructors shall not work fine as function
arguments (but we can use xsl:variable as workaround, for them).
> NullPointerException on use of arrow operator (1 to 5) => sum()
> ---
>
> Key: XALANJ-2746
> URL: https://issues.apache.org/jira/browse/XALANJ-2746
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan, Xalan-CmdLine
>Reporter: Martin Honnen
>Priority: Major
> Attachments: arrow-operator-test1.xsl
>
>
> This is a bug report on the XSLT 3 development branch of Xalan.
> I see that the arrow operator => has been implemented but I have written a
> simple test case that gives a NullPointerException:
> Sample XSLT (run against any XML input):
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> exclude-result-prefixes="xs">
>
>
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
> {code}
>
> gives an error java.lang.NullPointerException
> {noformat}
> file:///C:/Users/marti/IdeaProjects/xalan-java/../../OneDrive/Documents/xslt/blog-xslt-3-by-example/xalan-xslt3-tests/arrow-operator-test1.xsl;
> Zeilennummer10; Spaltennummer51; java.lang.NullPointerException{noformat}
> Expected result would be `15`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2746) NullPointerException on use of arrow operator (1 to 5) => sum()
[
https://issues.apache.org/jira/browse/XALANJ-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853020#comment-17853020
]
Mukul Gandhi commented on XALANJ-2746:
--
[~martin.honnen], you're right. This is a defect.
.
In-fact, Xalan-J's xsl3 implementation currently has limitation, where literal
sequence constructor expressions can be successfully parsed and shall function
correctly, only when they form an entire XPath expression. i.e, (1,2,3) shall
work fine with Xalan-J currently.
But Xalan-J currently cannot handle,
for e.g, ... (1,2,3) OR (1,2,3) ...
(i.e, when an xpath sequence constructor is preceded or followed by any valid
tokens)
As a little workaround, your example shall work fine if we make use of XSL
variables, for e.g as follows,
For kind information, for few other Xalan-J xpath expressions as well, for e.g
literal non-empty sequence constructors shall not work fine as function
arguments (but we can use xsl:variable as workaround, for them).
> NullPointerException on use of arrow operator (1 to 5) => sum()
> ---
>
> Key: XALANJ-2746
> URL: https://issues.apache.org/jira/browse/XALANJ-2746
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan, Xalan-CmdLine
>Reporter: Martin Honnen
>Priority: Major
> Attachments: arrow-operator-test1.xsl
>
>
> This is a bug report on the XSLT 3 development branch of Xalan.
> I see that the arrow operator => has been implemented but I have written a
> simple test case that gives a NullPointerException:
> Sample XSLT (run against any XML input):
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> exclude-result-prefixes="xs">
>
>
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
> {code}
>
> gives an error java.lang.NullPointerException
> {noformat}
> file:///C:/Users/marti/IdeaProjects/xalan-java/../../OneDrive/Documents/xslt/blog-xslt-3-by-example/xalan-xslt3-tests/arrow-operator-test1.xsl;
> Zeilennummer10; Spaltennummer51; java.lang.NullPointerException{noformat}
> Expected result would be `15`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2746) NullPointerException on use of arrow operator (1 to 5) => sum()
Martin Honnen created XALANJ-2746:
-
Summary: NullPointerException on use of arrow operator (1 to 5) =>
sum()
Key: XALANJ-2746
URL: https://issues.apache.org/jira/browse/XALANJ-2746
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: Xalan, Xalan-CmdLine
Reporter: Martin Honnen
Attachments: arrow-operator-test1.xsl
This is a bug report on the XSLT 3 development branch of Xalan.
I see that the arrow operator => has been implemented but I have written a
simple test case that gives a NullPointerException:
Sample XSLT (run against any XML input):
{code:java}
http://www.w3.org/1999/XSL/Transform;
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema;
exclude-result-prefixes="xs">
Run with at
{code}
gives an error java.lang.NullPointerException
{noformat}
file:///C:/Users/marti/IdeaProjects/xalan-java/../../OneDrive/Documents/xslt/blog-xslt-3-by-example/xalan-xslt3-tests/arrow-operator-test1.xsl;
Zeilennummer10; Spaltennummer51; java.lang.NullPointerException{noformat}
Expected result would be `15`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANJ-2742) xpath3.1 map and array function implementations
[ https://issues.apache.org/jira/browse/XALANJ-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851264#comment-17851264 ] Mukul Gandhi edited comment on XALANJ-2742 at 6/5/24 12:18 PM: --- Xalan-J's dev repos branch xalan-j_xslt3.0, currently has following map and array function implementations, Map functions : size, keys, contains, get, put, entry, remove, for-each Array functions : size, get, put, append, subarray, remove, insert-before, head, tail, reverse, join, for-each, filter, for-each-pair was (Author: mukul_gandhi): Xalan-J's dev repos branch xalan-j_xslt3.0, currently has following map and array function implementations, Map functions : size, keys, contains, get, put, entry, remove, for-each Array functions : size, get, put, append, subarray, remove, insert-before, head, tail, reverse, join, for-each, filter > xpath3.1 map and array function implementations > --- > > Key: XALANJ-2742 > URL: https://issues.apache.org/jira/browse/XALANJ-2742 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi > Priority: Major > > I'm creating this jira issue to track implementation of xpath3.1 map and > array functions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANJ-2742) xpath3.1 map and array function implementations
[ https://issues.apache.org/jira/browse/XALANJ-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851264#comment-17851264 ] Mukul Gandhi edited comment on XALANJ-2742 at 6/5/24 10:01 AM: --- Xalan-J's dev repos branch xalan-j_xslt3.0, currently has following map and array function implementations, Map functions : size, keys, contains, get, put, entry, remove, for-each Array functions : size, get, put, append, subarray, remove, insert-before, head, tail, reverse, join, for-each, filter was (Author: mukul_gandhi): Xalan-J's dev repos branch xalan-j_xslt3.0 currently has following map and array function implementations, map functions : size, keys, contains, get, put, entry, remove, for-each array functions : size, get, put, append, subarray, remove, insert-before, head, tail, reverse, join > xpath3.1 map and array function implementations > --- > > Key: XALANJ-2742 > URL: https://issues.apache.org/jira/browse/XALANJ-2742 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi > Priority: Major > > I'm creating this jira issue to track implementation of xpath3.1 map and > array functions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2745) implementation of xpath3.1 arrow operator, =>
[ https://issues.apache.org/jira/browse/XALANJ-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2745. -- Resolution: Fixed I'm resolving this issue as fixed, since implementation for this has been committed to Xalan-J's dev repos branch xalan-j_xslt3.0. > implementation of xpath3.1 arrow operator, => > - > > Key: XALANJ-2745 > URL: https://issues.apache.org/jira/browse/XALANJ-2745 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi >Priority: Major > > I'm creating this jira issue, to track implementation of XPath 3.1 arrow > operator, "=>". -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2745) implementation of xpath3.1 arrow operator, =>
Mukul Gandhi created XALANJ-2745: Summary: implementation of xpath3.1 arrow operator, => Key: XALANJ-2745 URL: https://issues.apache.org/jira/browse/XALANJ-2745 Project: XalanJ2 Issue Type: Task Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Components: Xalan-interpretive, XPath Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue, to track implementation of XPath 3.1 arrow operator, "=>". -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2744) xpath3.1 implementation of sequence type expressions for maps and arrays
[ https://issues.apache.org/jira/browse/XALANJ-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2744. -- Resolution: Fixed I'm resolving this issue as fixed. The implementation for this has been committed to xalan-j dev repos branch xalan-j_xslt3.0. With respect to this, the following xpath3.1 sequence type expressions have been implemented : array(*), array(typeName), map(*), map(typeName, typeName) > xpath3.1 implementation of sequence type expressions for maps and arrays > > > Key: XALANJ-2744 > URL: https://issues.apache.org/jira/browse/XALANJ-2744 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi > Priority: Major > > I'm creating this jira issue to track implementation of xpath3.1 sequence > type expressions for maps and arrays. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2744) xpath3.1 implementation of sequence type expressions for maps and arrays
Mukul Gandhi created XALANJ-2744: Summary: xpath3.1 implementation of sequence type expressions for maps and arrays Key: XALANJ-2744 URL: https://issues.apache.org/jira/browse/XALANJ-2744 Project: XalanJ2 Issue Type: Task Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Components: Xalan-interpretive, XPath Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue to track implementation of xpath3.1 sequence type expressions for maps and arrays. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2743) xpath3.1 implementation of 'cast as' and 'castable as' expressions
[ https://issues.apache.org/jira/browse/XALANJ-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2743. -- Resolution: Fixed I'm resolving this issue as fixed. The implementation for this has been committed to xalan-j dev repos branch xalan-j_xslt3.0. > xpath3.1 implementation of 'cast as' and 'castable as' expressions > -- > > Key: XALANJ-2743 > URL: https://issues.apache.org/jira/browse/XALANJ-2743 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi > Priority: Major > > I'm creating this jira issue to track implementation of xpath3.1 'cast as' > and 'castable as' expressions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2743) xpath3.1 implementation of 'cast as' and 'castable as' expressions
Mukul Gandhi created XALANJ-2743: Summary: xpath3.1 implementation of 'cast as' and 'castable as' expressions Key: XALANJ-2743 URL: https://issues.apache.org/jira/browse/XALANJ-2743 Project: XalanJ2 Issue Type: Task Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Components: Xalan-interpretive, XPath, XPath-function Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue to track implementation of xpath3.1 'cast as' and 'castable as' expressions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2742) xpath3.1 map and array function implementations
[ https://issues.apache.org/jira/browse/XALANJ-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851264#comment-17851264 ] Mukul Gandhi commented on XALANJ-2742: -- Xalan-J's dev repos branch xalan-j_xslt3.0 currently has following map and array function implementations, map functions : size, keys, contains, get, put, entry, remove, for-each array functions : size, get, put, append, subarray, remove, insert-before, head, tail, reverse, join > xpath3.1 map and array function implementations > --- > > Key: XALANJ-2742 > URL: https://issues.apache.org/jira/browse/XALANJ-2742 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi > Priority: Major > > I'm creating this jira issue to track implementation of xpath3.1 map and > array functions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2742) xpath3.1 map and array function implementations
Mukul Gandhi created XALANJ-2742: Summary: xpath3.1 map and array function implementations Key: XALANJ-2742 URL: https://issues.apache.org/jira/browse/XALANJ-2742 Project: XalanJ2 Issue Type: Task Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Components: Xalan-interpretive, XPath, XPath-function Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue to track implementation of xpath3.1 map and array functions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2741) xpath3.1 implementation of curly array constructor expressions, and empty arrays
[
https://issues.apache.org/jira/browse/XALANJ-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi resolved XALANJ-2741.
--
Resolution: Fixed
I'm resolving this issue as fixed. The implementation for this has been
committed to xalan-j dev repos branch xalan-j_xslt3.0.
> xpath3.1 implementation of curly array constructor expressions, and empty
> arrays
>
>
> Key: XALANJ-2741
> URL: https://issues.apache.org/jira/browse/XALANJ-2741
> Project: XalanJ2
> Issue Type: Task
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-interpretive, XPath
>Reporter: Mukul Gandhi
>Assignee: Mukul Gandhi
>Priority: Major
>
> I'm creating this jira issue to track implementation of xpath3.1 curly array
> constructors (i.e, array { ... }), and empty arrays (i.e, [] and array { }).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2741) xpath3.1 implementation of curly array constructor expressions, and empty arrays
Mukul Gandhi created XALANJ-2741:
Summary: xpath3.1 implementation of curly array constructor
expressions, and empty arrays
Key: XALANJ-2741
URL: https://issues.apache.org/jira/browse/XALANJ-2741
Project: XalanJ2
Issue Type: Task
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: Xalan-interpretive, XPath
Reporter: Mukul Gandhi
Assignee: Mukul Gandhi
I'm creating this jira issue to track implementation of xpath3.1 curly array
constructors (i.e, array { ... }), and empty arrays (i.e, [] and array { }).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2740) map:for-each(parse-json(...), ..) gives error FORG0006 : The 1st argument to function call map:for-each, is not a map
[
https://issues.apache.org/jira/browse/XALANJ-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi resolved XALANJ-2740.
--
Resolution: Fixed
I'm resolving this jira issue as fixed. The fix for this has been committed
with id 8046925df73925d559225f4b092bf87012950537.
> map:for-each(parse-json(...), ..) gives error FORG0006 : The 1st argument to
> function call map:for-each, is not a map
> -
>
> Key: XALANJ-2740
> URL: https://issues.apache.org/jira/browse/XALANJ-2740
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-CmdLine
>Affects Versions: The Latest Development Code
> Environment: Windows 11, Java 8
>Reporter: Martin Honnen
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: map-for-each-test3.xsl, xml-sample-with-json-data2.xml
>
>
> This is a bug report on the XSLT 3.0 development branch of Xalan.
> In my attempt to try the new implementation of parse-json and map function I
> have written code like
> {code:java}
>
>
>
>
> {code}
>
> but that gives an error "FORG0006 : The 1st argument to function call
> map:for-each, is not a map".
> As a workaround it appears that using a variable works:
> {code:java}
>
>
>
>
>
> {code}
>
> But it seems to me that the original expression should work too.
> Full files attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Assigned] (XALANJ-2740) map:for-each(parse-json(...), ..) gives error FORG0006 : The 1st argument to function call map:for-each, is not a map
[
https://issues.apache.org/jira/browse/XALANJ-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi reassigned XALANJ-2740:
Assignee: Mukul Gandhi
> map:for-each(parse-json(...), ..) gives error FORG0006 : The 1st argument to
> function call map:for-each, is not a map
> -
>
> Key: XALANJ-2740
> URL: https://issues.apache.org/jira/browse/XALANJ-2740
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-CmdLine
>Affects Versions: The Latest Development Code
> Environment: Windows 11, Java 8
>Reporter: Martin Honnen
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: map-for-each-test3.xsl, xml-sample-with-json-data2.xml
>
>
> This is a bug report on the XSLT 3.0 development branch of Xalan.
> In my attempt to try the new implementation of parse-json and map function I
> have written code like
> {code:java}
>
>
>
>
> {code}
>
> but that gives an error "FORG0006 : The 1st argument to function call
> map:for-each, is not a map".
> As a workaround it appears that using a variable works:
> {code:java}
>
>
>
>
>
> {code}
>
> But it seems to me that the original expression should work too.
> Full files attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2740) map:for-each(parse-json(...), ..) gives error FORG0006 : The 1st argument to function call map:for-each, is not a map
Martin Honnen created XALANJ-2740:
-
Summary: map:for-each(parse-json(...), ..) gives error FORG0006 :
The 1st argument to function call map:for-each, is not a map
Key: XALANJ-2740
URL: https://issues.apache.org/jira/browse/XALANJ-2740
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: Xalan-CmdLine
Affects Versions: The Latest Development Code
Environment: Windows 11, Java 8
Reporter: Martin Honnen
Attachments: map-for-each-test3.xsl, xml-sample-with-json-data2.xml
This is a bug report on the XSLT 3.0 development branch of Xalan.
In my attempt to try the new implementation of parse-json and map function I
have written code like
{code:java}
{code}
but that gives an error "FORG0006 : The 1st argument to function call
map:for-each, is not a map".
As a workaround it appears that using a variable works:
{code:java}
{code}
But it seems to me that the original expression should work too.
Full files attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2739) map:get on values returned by map:keys doesn't find a map entry
[
https://issues.apache.org/jira/browse/XALANJ-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi resolved XALANJ-2739.
--
Resolution: Fixed
I'm marking this issue as resolved. The fix for this has been committed to
xalanj xsl3 dev repos branch, with commit id
c12291090d5917df8d952875e12b3de9dab45bec.
> map:get on values returned by map:keys doesn't find a map entry
> ---
>
> Key: XALANJ-2739
> URL: https://issues.apache.org/jira/browse/XALANJ-2739
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-CmdLine
>Affects Versions: The Latest Development Code
> Environment: Windows 11, Java 8
>Reporter: Martin Honnen
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: for-return-map-keys1.xsl
>
>
> This is a bug report on the XSLT 3.0 development branch of Xalan.
> I have tried the new XDM/XPath 3.1 map feature but I see some odd failure,
> the function map:keys returns a sequence of (supposedly) map key values but
> somehow using map:get with those keys doesn't find any value.
>
> XSLT code (run against any XML input file):
>
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> xmlns:map="http://www.w3.org/2005/xpath-functions/map;
> xmlns:array="http://www.w3.org/2005/xpath-functions/array;
> exclude-result-prefixes="xs map array">
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
>
> Result is e.g.
> {code:java}
>
>
> bar
>
>
>
>
> {code}
> so somehow the returned keys from map:keys don't work as intended with
> map:get.
>
> Expected result would include e.g.
>
> {code:java}
>
> bar
> 1 2 3
> {code}
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Assigned] (XALANJ-2739) map:get on values returned by map:keys doesn't find a map entry
[
https://issues.apache.org/jira/browse/XALANJ-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi reassigned XALANJ-2739:
Assignee: Mukul Gandhi
> map:get on values returned by map:keys doesn't find a map entry
> ---
>
> Key: XALANJ-2739
> URL: https://issues.apache.org/jira/browse/XALANJ-2739
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-CmdLine
>Affects Versions: The Latest Development Code
> Environment: Windows 11, Java 8
>Reporter: Martin Honnen
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: for-return-map-keys1.xsl
>
>
> This is a bug report on the XSLT 3.0 development branch of Xalan.
> I have tried the new XDM/XPath 3.1 map feature but I see some odd failure,
> the function map:keys returns a sequence of (supposedly) map key values but
> somehow using map:get with those keys doesn't find any value.
>
> XSLT code (run against any XML input file):
>
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> xmlns:map="http://www.w3.org/2005/xpath-functions/map;
> xmlns:array="http://www.w3.org/2005/xpath-functions/array;
> exclude-result-prefixes="xs map array">
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
>
> Result is e.g.
> {code:java}
>
>
> bar
>
>
>
>
> {code}
> so somehow the returned keys from map:keys don't work as intended with
> map:get.
>
> Expected result would include e.g.
>
> {code:java}
>
> bar
> 1 2 3
> {code}
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2738) getting error "The 1st argument of array:get function call, needs to be an xdm array" on map:get of XDM map returned by parse-json which should be XDM array
[
https://issues.apache.org/jira/browse/XALANJ-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi resolved XALANJ-2738.
--
Resolution: Fixed
I'm marking this issue as resolved. The fix for this has been committed, within
commit id c7fdf07c1240eca86d5481950379c1246edbfaa6.
> getting error "The 1st argument of array:get function call, needs to be an
> xdm array" on map:get of XDM map returned by parse-json which should be XDM
> array
>
>
> Key: XALANJ-2738
> URL: https://issues.apache.org/jira/browse/XALANJ-2738
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-interpretive
>Affects Versions: The Latest Development Code
> Environment: Windows 11, Java 8
>Reporter: Martin Honnen
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: parse-json-test1.xsl, xml-sample-with-json-data1.xml
>
>
> This is a bug report on the XSLT 3.0 development branch of Xalan.
>
> I have tried to use an XPath 3.1 array function like array:get on the result
> of calling map:get on the result of parse-json and while that works fine in
> an XSLT 3 processor like Saxon HE 12 for Xalan it fails with "The 1st
> argument of array:get function call, needs to be an xdm array".
>
> Here is the code, XML sample:
> {code:java}
>
> { "foo" : "bar", "data" : [1,2,3] }
> {code}
>
> XSLT:
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> xmlns:map="http://www.w3.org/2005/xpath-functions/map;
> xmlns:array="http://www.w3.org/2005/xpath-functions/array;
> exclude-result-prefixes="xs map array">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
> {code}
>
>
> Results in error
> {noformat}
> file:///C:/Users/marti/IdeaProjects/xalan-java/../../OneDrive/Documents/xslt/blog-xslt-3-by-example/xalan-xslt3-tests/parse-json-test1.xsl;
> Zeilennummer21; Spaltennummer72; javax.xml.transform.TransformerException:
> FORG0006 : The 1st argument of array:get function call, needs to be an xdm
> array{noformat}
>
> The expected result is the value 1 in the comment as the expression
> `array:get(map:get($json-map, 'data'), 1)` should just select the XDM array
> and read out its first array item, the number value 1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Updated] (XALANJ-2739) map:get on values returned by map:keys doesn't find a map entry
[
https://issues.apache.org/jira/browse/XALANJ-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Honnen updated XALANJ-2739:
--
Attachment: for-return-map-keys1.xsl
> map:get on values returned by map:keys doesn't find a map entry
> ---
>
> Key: XALANJ-2739
> URL: https://issues.apache.org/jira/browse/XALANJ-2739
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-CmdLine
>Affects Versions: The Latest Development Code
> Environment: Windows 11, Java 8
>Reporter: Martin Honnen
>Priority: Major
> Attachments: for-return-map-keys1.xsl
>
>
> This is a bug report on the XSLT 3.0 development branch of Xalan.
> I have tried the new XDM/XPath 3.1 map feature but I see some odd failure,
> the function map:keys returns a sequence of (supposedly) map key values but
> somehow using map:get with those keys doesn't find any value.
>
> XSLT code (run against any XML input file):
>
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> xmlns:map="http://www.w3.org/2005/xpath-functions/map;
> xmlns:array="http://www.w3.org/2005/xpath-functions/array;
> exclude-result-prefixes="xs map array">
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
>
> Result is e.g.
> {code:java}
>
>
> bar
>
>
>
>
> {code}
> so somehow the returned keys from map:keys don't work as intended with
> map:get.
>
> Expected result would include e.g.
>
> {code:java}
>
> bar
> 1 2 3
> {code}
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2739) map:get on values returned by map:keys doesn't find a map entry
Martin Honnen created XALANJ-2739:
-
Summary: map:get on values returned by map:keys doesn't find a map
entry
Key: XALANJ-2739
URL: https://issues.apache.org/jira/browse/XALANJ-2739
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: Xalan-CmdLine
Affects Versions: The Latest Development Code
Environment: Windows 11, Java 8
Reporter: Martin Honnen
This is a bug report on the XSLT 3.0 development branch of Xalan.
I have tried the new XDM/XPath 3.1 map feature but I see some odd failure, the
function map:keys returns a sequence of (supposedly) map key values but somehow
using map:get with those keys doesn't find any value.
XSLT code (run against any XML input file):
{code:java}
http://www.w3.org/1999/XSL/Transform;
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema;
xmlns:map="http://www.w3.org/2005/xpath-functions/map;
xmlns:array="http://www.w3.org/2005/xpath-functions/array;
exclude-result-prefixes="xs map array">
Run with at
{code}
Result is e.g.
{code:java}
bar
{code}
so somehow the returned keys from map:keys don't work as intended with map:get.
Expected result would include e.g.
{code:java}
bar
1 2 3
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2738) getting error "The 1st argument of array:get function call, needs to be an xdm array" on map:get of XDM map returned by parse-json which should be XDM array
[
https://issues.apache.org/jira/browse/XALANJ-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850268#comment-17850268
]
Mukul Gandhi commented on XALANJ-2738:
--
[~martin.honnen], hoping to look at this issue at earliest. just been busy with
few other tasks.
> getting error "The 1st argument of array:get function call, needs to be an
> xdm array" on map:get of XDM map returned by parse-json which should be XDM
> array
>
>
> Key: XALANJ-2738
> URL: https://issues.apache.org/jira/browse/XALANJ-2738
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-interpretive
>Affects Versions: The Latest Development Code
> Environment: Windows 11, Java 8
>Reporter: Martin Honnen
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: parse-json-test1.xsl, xml-sample-with-json-data1.xml
>
>
> This is a bug report on the XSLT 3.0 development branch of Xalan.
>
> I have tried to use an XPath 3.1 array function like array:get on the result
> of calling map:get on the result of parse-json and while that works fine in
> an XSLT 3 processor like Saxon HE 12 for Xalan it fails with "The 1st
> argument of array:get function call, needs to be an xdm array".
>
> Here is the code, XML sample:
> {code:java}
>
> { "foo" : "bar", "data" : [1,2,3] }
> {code}
>
> XSLT:
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> xmlns:map="http://www.w3.org/2005/xpath-functions/map;
> xmlns:array="http://www.w3.org/2005/xpath-functions/array;
> exclude-result-prefixes="xs map array">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
> {code}
>
>
> Results in error
> {noformat}
> file:///C:/Users/marti/IdeaProjects/xalan-java/../../OneDrive/Documents/xslt/blog-xslt-3-by-example/xalan-xslt3-tests/parse-json-test1.xsl;
> Zeilennummer21; Spaltennummer72; javax.xml.transform.TransformerException:
> FORG0006 : The 1st argument of array:get function call, needs to be an xdm
> array{noformat}
>
> The expected result is the value 1 in the comment as the expression
> `array:get(map:get($json-map, 'data'), 1)` should just select the XDM array
> and read out its first array item, the number value 1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Assigned] (XALANJ-2738) getting error "The 1st argument of array:get function call, needs to be an xdm array" on map:get of XDM map returned by parse-json which should be XDM array
[
https://issues.apache.org/jira/browse/XALANJ-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mukul Gandhi reassigned XALANJ-2738:
Assignee: Mukul Gandhi
> getting error "The 1st argument of array:get function call, needs to be an
> xdm array" on map:get of XDM map returned by parse-json which should be XDM
> array
>
>
> Key: XALANJ-2738
> URL: https://issues.apache.org/jira/browse/XALANJ-2738
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Xalan-interpretive
>Affects Versions: The Latest Development Code
> Environment: Windows 11, Java 8
>Reporter: Martin Honnen
>Assignee: Mukul Gandhi
>Priority: Major
> Attachments: parse-json-test1.xsl, xml-sample-with-json-data1.xml
>
>
> This is a bug report on the XSLT 3.0 development branch of Xalan.
>
> I have tried to use an XPath 3.1 array function like array:get on the result
> of calling map:get on the result of parse-json and while that works fine in
> an XSLT 3 processor like Saxon HE 12 for Xalan it fails with "The 1st
> argument of array:get function call, needs to be an xdm array".
>
> Here is the code, XML sample:
> {code:java}
>
> { "foo" : "bar", "data" : [1,2,3] }
> {code}
>
> XSLT:
>
> {code:java}
>
> http://www.w3.org/1999/XSL/Transform;
> version="3.0"
> xmlns:xs="http://www.w3.org/2001/XMLSchema;
> xmlns:map="http://www.w3.org/2005/xpath-functions/map;
> xmlns:array="http://www.w3.org/2005/xpath-functions/array;
> exclude-result-prefixes="xs map array">
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Run with select="system-property('xsl:vendor')"/> at select="current-dateTime()"/>
>
>
>
> {code}
>
>
> Results in error
> {noformat}
> file:///C:/Users/marti/IdeaProjects/xalan-java/../../OneDrive/Documents/xslt/blog-xslt-3-by-example/xalan-xslt3-tests/parse-json-test1.xsl;
> Zeilennummer21; Spaltennummer72; javax.xml.transform.TransformerException:
> FORG0006 : The 1st argument of array:get function call, needs to be an xdm
> array{noformat}
>
> The expected result is the value 1 in the comment as the expression
> `array:get(map:get($json-map, 'data'), 1)` should just select the XDM array
> and read out its first array item, the number value 1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2738) getting error "The 1st argument of array:get function call, needs to be an xdm array" on map:get of XDM map returned by parse-json which should be XDM array
Martin Honnen created XALANJ-2738:
-
Summary: getting error "The 1st argument of array:get function
call, needs to be an xdm array" on map:get of XDM map returned by parse-json
which should be XDM array
Key: XALANJ-2738
URL: https://issues.apache.org/jira/browse/XALANJ-2738
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Components: Xalan-interpretive
Affects Versions: The Latest Development Code
Environment: Windows 11, Java 8
Reporter: Martin Honnen
Attachments: parse-json-test1.xsl, xml-sample-with-json-data1.xml
This is a bug report on the XSLT 3.0 development branch of Xalan.
I have tried to use an XPath 3.1 array function like array:get on the result of
calling map:get on the result of parse-json and while that works fine in an
XSLT 3 processor like Saxon HE 12 for Xalan it fails with "The 1st argument of
array:get function call, needs to be an xdm array".
Here is the code, XML sample:
{code:java}
{ "foo" : "bar", "data" : [1,2,3] }
{code}
XSLT:
{code:java}
http://www.w3.org/1999/XSL/Transform;
version="3.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema;
xmlns:map="http://www.w3.org/2005/xpath-functions/map;
xmlns:array="http://www.w3.org/2005/xpath-functions/array;
exclude-result-prefixes="xs map array">
Run with at
{code}
Results in error
{noformat}
file:///C:/Users/marti/IdeaProjects/xalan-java/../../OneDrive/Documents/xslt/blog-xslt-3-by-example/xalan-xslt3-tests/parse-json-test1.xsl;
Zeilennummer21; Spaltennummer72; javax.xml.transform.TransformerException:
FORG0006 : The 1st argument of array:get function call, needs to be an xdm
array{noformat}
The expected result is the value 1 in the comment as the expression
`array:get(map:get($json-map, 'data'), 1)` should just select the XDM array and
read out its first array item, the number value 1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2737) implementation of xpath 3.1 function fn:parse-json, for xalan-j's interpretive processor
[ https://issues.apache.org/jira/browse/XALANJ-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2737. -- Resolution: Fixed I'm resolving this issue as fixed, since implementation for this has been committed to Xalan-J's code repos branch xalan-j_xslt3.0. > implementation of xpath 3.1 function fn:parse-json, for xalan-j's > interpretive processor > > > Key: XALANJ-2737 > URL: https://issues.apache.org/jira/browse/XALANJ-2737 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi >Priority: Major > > I'm creating this jira issue, to track implementation of XPath 3.1 function > fn:parse-json for Xalan-J's interpretive processor. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2737) implementation of xpath 3.1 function fn:parse-json, for xalan-j's interpretive processor
Mukul Gandhi created XALANJ-2737: Summary: implementation of xpath 3.1 function fn:parse-json, for xalan-j's interpretive processor Key: XALANJ-2737 URL: https://issues.apache.org/jira/browse/XALANJ-2737 Project: XalanJ2 Issue Type: Task Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Components: Xalan-interpretive, XPath, XPath-function Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue, to track implementation of XPath 3.1 function fn:parse-json for Xalan-J's interpretive processor. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2736) implementation of xpath 3.1 map expressions and map lookup using function call syntax
[ https://issues.apache.org/jira/browse/XALANJ-2736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2736. -- Resolution: Fixed I'm marking this jira issue as fixed, since implementation for this has been committed to xalanj dev repos branch xalan-j_xslt3.0. > implementation of xpath 3.1 map expressions and map lookup using function > call syntax > - > > Key: XALANJ-2736 > URL: https://issues.apache.org/jira/browse/XALANJ-2736 > Project: XalanJ2 > Issue Type: Task > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan-interpretive, XPath >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi >Priority: Major > > I'm creating this jira issue, to track implementation of XPath 3.1 map > expressions and map lookup using function call syntax. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2736) implementation of xpath 3.1 map expressions and map lookup using function call syntax
Mukul Gandhi created XALANJ-2736: Summary: implementation of xpath 3.1 map expressions and map lookup using function call syntax Key: XALANJ-2736 URL: https://issues.apache.org/jira/browse/XALANJ-2736 Project: XalanJ2 Issue Type: Task Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Components: Xalan-interpretive, XPath Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue, to track implementation of XPath 3.1 map expressions and map lookup using function call syntax. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Updated] (XALANJ-2735) xpath3.1 functions related to QName data type
[ https://issues.apache.org/jira/browse/XALANJ-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi updated XALANJ-2735: - Issue Type: New Feature (was: Wish) Summary: xpath3.1 functions related to QName data type (was: xpath 3 functions related to QNames) > xpath3.1 functions related to QName data type > - > > Key: XALANJ-2735 > URL: https://issues.apache.org/jira/browse/XALANJ-2735 > Project: XalanJ2 > Issue Type: New Feature > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi >Priority: Minor > > I think, that it'll be useful for Xalan users of Xalan's xslt 3 development > code, to have implementations available for XPath 3 functions related to > QNames (please see section "10 Functions related to QNames" of XPath 3.1 F > spec for requirements related to this). > I'm creating this jira issue, in case anyone from Xalan community may wish to > implement these. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2735) xpath 3 functions related to QNames
[ https://issues.apache.org/jira/browse/XALANJ-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2735. -- Assignee: Mukul Gandhi Resolution: Fixed Implementations of following xpath3.1 functions were committed today to xalan-j repos branch xalan-j_xslt3.0 : fn:resolve-QName, fn:QName, fn:prefix-from-QName, fn:local-name-from-QName, fn:namespace-uri-from-QName, fn:namespace-uri-for-prefix, fn:in-scope-prefixes. I'm therefore specifying this jira issue as resolved. > xpath 3 functions related to QNames > --- > > Key: XALANJ-2735 > URL: https://issues.apache.org/jira/browse/XALANJ-2735 > Project: XalanJ2 > Issue Type: Wish > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: XPath, XPath-function >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi >Priority: Minor > > I think, that it'll be useful for Xalan users of Xalan's xslt 3 development > code, to have implementations available for XPath 3 functions related to > QNames (please see section "10 Functions related to QNames" of XPath 3.1 F > spec for requirements related to this). > I'm creating this jira issue, in case anyone from Xalan community may wish to > implement these. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2735) xpath 3 functions related to QNames
Mukul Gandhi created XALANJ-2735: Summary: xpath 3 functions related to QNames Key: XALANJ-2735 URL: https://issues.apache.org/jira/browse/XALANJ-2735 Project: XalanJ2 Issue Type: Wish Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Components: XPath, XPath-function Reporter: Mukul Gandhi I think, that it'll be useful for Xalan users of Xalan's xslt 3 development code, to have implementations available for XPath 3 functions related to QNames (please see section "10 Functions related to QNames" of XPath 3.1 F spec for requirements related to this). I'm creating this jira issue, in case anyone from Xalan community may wish to implement these. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANC-743) XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till out of memory
[ https://issues.apache.org/jira/browse/XALANC-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829379#comment-17829379 ] Daehyeon Kim edited comment on XALANC-743 at 4/2/24 5:51 AM: - I also met this problem. Appears to be a very similar issue to the issue reported in XALANJ-2419. If transforming when Unicode supplementary characters are included in the input, the output will be corrupted. Also confirmed that both Xalan-C++ versions 1.10 to 1.12 have the same problem. This problem appears for for both UTF-16 output encoding and UTF-8 output encoding. When using UTF16Writer, supplementary characters are converted to broken characters such as "??". If using UTF8Writer, a more serious problem arises where no output results are obtained. This suggests a higher-level issue than serialization, with something suspicious found in the XPath FunctionSubstring implementation. There's no issue with UTF16Writer and UTF8Writer. XPath FunctionSubstring takes a character index position as an argument. A surrogate pair needs to be counted as one character (as per the XPath Recommendation). Thus, the string buffer positions where the surrogate pair is considered at the character index need to be counted. Currently, Xalan truncates the string buffer only with the arguments received for the character index. This will causing the truncated string to be corrupted when the surrogate pair is in the string buffer. The same applies to this issue. If a string containing supplementary characters is incorrectly truncated in FunctionSubstring, surrogate pairs (which cannot appear in UTF-8) may surprisingly appear in UTF8Writer (as evident in the assertion in UTF8Writer "// We should never get a high or low surrogate here..."). Therefore, fixing XPath FunctionSubstring to count the string data length considering the surrogate pair resolves this issue automatically. Please refer to the pull request for the changed code. was (Author: JIRAUSER304680): I also met this problem. Appears to be a very similar issue to the issue reported in XALANJ-2419. If transforming when Unicode supplementary characters are included in the input, the output will be corrupted. Also confirmed that both Xalan-C++ versions 1.10 to 1.12 have the same problem. This problem appears for for both UTF-16 output encoding and UTF-8 output encoding. When using UTF16Writer, supplementary characters are converted to broken characters such as "??". If using UTF8Writer, a more serious problem arises where no output results are obtained. This suggests a higher-level issue than serialization, with something suspicious found in the XPath FunctionSubstring implementation. There's no issue with UTF16Writer and UTF8Writer. XPath FunctionSubstring takes a character index position as an argument. A surrogate pair needs to be counted as one character (as per the XPath Recommendation). Thus, the string buffer positions where the surrogate pair is considered at the character index need to be counted. Currently, Xalan truncates the string buffer only with the arguments received for the character index, causing the truncated string to be corrupted when the surrogate pair is in the string buffer. The same applies to this issue. If a string containing supplementary characters is incorrectly truncated in FunctionSubstring, surrogate pairs (which cannot appear in UTF-8) may surprisingly appear in UTF8Writer (as evident in the assertion in UTF8Writer "// We should never get a high or low surrogate here..."). Therefore, fixing XPath FunctionSubstring to count the string data length considering the surrogate pair resolves this issue automatically. Please refer to the pull request for the changed code. > XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till > out of memory > --- > > Key: XALANC-743 > URL: https://issues.apache.org/jira/browse/XALANC-743 > Project: XalanC > Issue Type: Bug > Components: XalanC >Affects Versions: 1.10 > Environment: Linux >Reporter: Jiangbei Fan >Assignee: Steven J. Hathaway >Priority: Major > > In some rare cases, XalanTransformer::transform would stuck or crash when the > input/stylesheet contains 4-byte unicode. And I traced down the root cause in > XalanOutputStream::transcode > When the transcode buffer contains unicode of size 4 bytes, and the last > XalanDOMChar in the buffer is the first 2 bytes of a 4-byte unicode char. The > XalanOutputStream::transcode will fall into an infinite loop till it is out > of memory. As XMLUTF8Transcoder.cpp in xerces will not
[jira] [Comment Edited] (XALANC-743) XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till out of memory
[ https://issues.apache.org/jira/browse/XALANC-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829379#comment-17829379 ] Daehyeon Kim edited comment on XALANC-743 at 4/2/24 5:48 AM: - I also met this problem. Appears to be a very similar issue to the issue reported in XALANJ-2419. If transforming when Unicode supplementary characters are included in the input, the output will be corrupted. Also confirmed that both Xalan-C++ versions 1.10 to 1.12 have the same problem. This problem appears for for both UTF-16 output encoding and UTF-8 output encoding. When using UTF16Writer, supplementary characters are converted to broken characters such as "??". If using UTF8Writer, a more serious problem arises where no output results are obtained. This suggests a higher-level issue than serialization, with something suspicious found in the XPath FunctionSubstring implementation. There's no issue with UTF16Writer and UTF8Writer. XPath FunctionSubstring takes a character index position as an argument. A surrogate pair needs to be counted as one character (as per the XPath Recommendation). Thus, the string buffer positions where the surrogate pair is considered at the character index need to be counted. Currently, Xalan truncates the string buffer only with the arguments received for the character index, causing the truncated string to be corrupted when the surrogate pair is in the string buffer. The same applies to this issue. If a string containing supplementary characters is incorrectly truncated in FunctionSubstring, surrogate pairs (which cannot appear in UTF-8) may surprisingly appear in UTF8Writer (as evident in the assertion in UTF8Writer "// We should never get a high or low surrogate here..."). Therefore, fixing XPath FunctionSubstring to count the string data length considering the surrogate pair resolves this issue automatically. Please refer to the pull request for the changed code. was (Author: JIRAUSER304680): This appears to be a very similar issue to the issue reported in XALANJ-2419. If you transform when Unicode supplementary characters is included in the input, the output will be corrupted. I also confirmed that both Xalan-C++ versions 1.10 to 1.12 have the same problem. I fixed this problem. This problem appears for both UTF-16 output encoding and UTF-8 output encoding. When using UTF16Writer, supplementary characters are converted to broken characters such as "??". If you use UTF8Writer you will have a more serious problem where you will not even get broken characters and transform will get no output results. This means there may be a problem at a higher level than serialization, and I found something suspicious in the XPath FunctionSubstring implementation. There is no problem with UTF16Writer and UTF8Writer. XPath FunctionSubstring takes a character index position as an argument. And a surrogate pair needs to be counted as one character (as the XPath Recommendation ([https://www.w3.org/TR/xpath-functions-31/#func-substring])). So we need to count the string buffer positions where the surrogate pair is considered at the character index. But now xalan truncates the string buffer only with the arguments received the character index. This will cause the truncated string to be corrupted when the surrogate pair is in the string buffer. The same goes for this issue. If a string containing supplementary characters is incorrectly truncated in FunstionSubstring, surrogate pairs (which cannot appear in UTF-8) may surprisingly appear in UTF8Writer..(and this can also be seen in the assertion in UTF8Writer "// We should never get a high or low surrogate here..."). So I fixed the XPath FunctionSubstring to count the string data length considering the surrogate pair. Then this issue will be automatically resolved. Please refer to the pull request to see the changed code. > XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till > out of memory > --- > > Key: XALANC-743 > URL: https://issues.apache.org/jira/browse/XALANC-743 > Project: XalanC > Issue Type: Bug > Components: XalanC >Affects Versions: 1.10 > Environment: Linux >Reporter: Jiangbei Fan >Assignee: Steven J. Hathaway >Priority: Major > > In some rare cases, XalanTransformer::transform would stuck or crash when the > input/stylesheet contains 4-byte unicode. And I traced down the root cause in > XalanOutputStream::transcode > When the transcode buffer contains unicode of size 4 bytes, and the last > XalanDOMChar in the buffer is the first 2 bytes of a 4-byte unicode c
[jira] [Resolved] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman resolved XALANJ-2650. --- Resolution: Fixed > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Joseph Kessselman >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2436) Xalan must not expose bundled classes (bcel, regexp)
[ https://issues.apache.org/jira/browse/XALANJ-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831612#comment-17831612 ] Joe Kesselman commented on XALANJ-2436: --- Uhm. If we rename, that avoids our being vulnerable to getting the wrong version but makes deliberately overriding with a newer version harder. (Not impossible but it requires mucking with the jarfile.) If we don't, we block someone else's needing a version we have issues with, should that ever arise. And it's possible to create a case where dependencies are intertwined such that there is no way for everyone to get exactly what they want without separate class loaders. I agree that the Endorsed case should no longer be an issue -- but that was achieved precisely by shading Sun's copy of Xalan and having a runtime selection of the proper package via a factory, so we could continue to use the "native" org.apache packages. Basically, if you have runtime linking via the classpaths you are going to have exposures and have to decide which is least objectionable. The clean answers are either that we don't bundle the dependencies into our jarfile, or that we do so but rename as private copies, or we go full private loaders such as OSGI. I"m not wild about any of them. It's very much a matter of least-worst. I'm open to arguments. But we might want to take that debate to the list, shelving this work item pending consensus... > Xalan must not expose bundled classes (bcel, regexp) > > > Key: XALANJ-2436 > URL: https://issues.apache.org/jira/browse/XALANJ-2436 > Project: XalanJ2 > Issue Type: Bug > Components: Xalan >Affects Versions: 2.7.1 > Environment: any >Reporter: Holger Hoffstätte >Assignee: Joseph Kessselman >Priority: Critical > Attachments: XALAN-2436.patch, rewrite-packages.rules > > > I just spent the better part of half a day figuring out what caused the > problem outlined in > https://sourceforge.net/tracker/?func=detail=614693=1902137_id=96405. > Xalan bundles regexp and bcel, however since one of the recommened ways of > installing xalan is via the endorsed mechanism this will wreak serious havoc > on any other apps that use bcel. That would be less of a problem is xalan's > version were up to date, but as of 2.7.1 it still includes a version from the > early stone age (see XALANJ-2423). The solution is easy: when building the > aggregate jar, add an ant task to rewrite the bundled packages via jarjar > (http://code.google.com/p/jarjar/). This can be trivially added to the build > and creates a completely self-contained xalan jar that will not blow up the > world when endorsed. > I will attach a trivial rule file for jarjar that rewrites the embedded > packages which should immediately fix any collision problems. For more > information about how to use jarjar, see > http://code.google.com/p/jarjar/wiki/GettingStarted -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANJ-2436) Xalan must not expose bundled classes (bcel, regexp)
[ https://issues.apache.org/jira/browse/XALANJ-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831604#comment-17831604 ] Gary D. Gregory edited comment on XALANJ-2436 at 3/28/24 2:10 AM: -- The endorsed mechanism does not apply to Java 8 so I don't think we need to worry about that use case. I'm really don't like shadding on top of it especially if that comes with a change in package name, it makes it impossible to update a code if it has a CVE or a bug. was (Author: garydgregory): The endorsed mechanism does not apply to Java 8 so I don't think we need to worry about that use case. I'm really don't like shedding on top of it especially if that comes with a change in package name, it makes it impossible to update a code if it has a CVE or a bug. > Xalan must not expose bundled classes (bcel, regexp) > > > Key: XALANJ-2436 > URL: https://issues.apache.org/jira/browse/XALANJ-2436 > Project: XalanJ2 > Issue Type: Bug > Components: Xalan >Affects Versions: 2.7.1 > Environment: any >Reporter: Holger Hoffstätte >Assignee: Joseph Kessselman >Priority: Critical > Attachments: XALAN-2436.patch, rewrite-packages.rules > > > I just spent the better part of half a day figuring out what caused the > problem outlined in > https://sourceforge.net/tracker/?func=detail=614693=1902137_id=96405. > Xalan bundles regexp and bcel, however since one of the recommened ways of > installing xalan is via the endorsed mechanism this will wreak serious havoc > on any other apps that use bcel. That would be less of a problem is xalan's > version were up to date, but as of 2.7.1 it still includes a version from the > early stone age (see XALANJ-2423). The solution is easy: when building the > aggregate jar, add an ant task to rewrite the bundled packages via jarjar > (http://code.google.com/p/jarjar/). This can be trivially added to the build > and creates a completely self-contained xalan jar that will not blow up the > world when endorsed. > I will attach a trivial rule file for jarjar that rewrites the embedded > packages which should immediately fix any collision problems. For more > information about how to use jarjar, see > http://code.google.com/p/jarjar/wiki/GettingStarted -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2436) Xalan must not expose bundled classes (bcel, regexp)
[ https://issues.apache.org/jira/browse/XALANJ-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831604#comment-17831604 ] Gary D. Gregory commented on XALANJ-2436: - The endorsed mechanism does not apply to Java 8 so I don't think we need to worry about that use case. I'm really don't like shedding on top of it especially if that comes with a change in package name, it makes it impossible to update a code if it has a CVE or a bug. > Xalan must not expose bundled classes (bcel, regexp) > > > Key: XALANJ-2436 > URL: https://issues.apache.org/jira/browse/XALANJ-2436 > Project: XalanJ2 > Issue Type: Bug > Components: Xalan >Affects Versions: 2.7.1 > Environment: any >Reporter: Holger Hoffstätte >Assignee: Joseph Kessselman >Priority: Critical > Attachments: XALAN-2436.patch, rewrite-packages.rules > > > I just spent the better part of half a day figuring out what caused the > problem outlined in > https://sourceforge.net/tracker/?func=detail=614693=1902137_id=96405. > Xalan bundles regexp and bcel, however since one of the recommened ways of > installing xalan is via the endorsed mechanism this will wreak serious havoc > on any other apps that use bcel. That would be less of a problem is xalan's > version were up to date, but as of 2.7.1 it still includes a version from the > early stone age (see XALANJ-2423). The solution is easy: when building the > aggregate jar, add an ant task to rewrite the bundled packages via jarjar > (http://code.google.com/p/jarjar/). This can be trivially added to the build > and creates a completely self-contained xalan jar that will not blow up the > world when endorsed. > I will attach a trivial rule file for jarjar that rewrites the embedded > packages which should immediately fix any collision problems. For more > information about how to use jarjar, see > http://code.google.com/p/jarjar/wiki/GettingStarted -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] (XALANJ-2436) Xalan must not expose bundled classes (bcel, regexp)
[ https://issues.apache.org/jira/browse/XALANJ-2436 ] Joseph Kessselman deleted comment on XALANJ-2436: --- was (Author: JIRAUSER285361): The Maven build currently on Master's HEAD addresses this by using Maven's "shading" plug-in. If we want to release patches for 2.7.3 and earlier, jarjar looks like a good solution. > Xalan must not expose bundled classes (bcel, regexp) > > > Key: XALANJ-2436 > URL: https://issues.apache.org/jira/browse/XALANJ-2436 > Project: XalanJ2 > Issue Type: Bug > Components: Xalan >Affects Versions: 2.7.1 > Environment: any >Reporter: Holger Hoffstätte >Assignee: Joseph Kessselman >Priority: Critical > Attachments: XALAN-2436.patch, rewrite-packages.rules > > > I just spent the better part of half a day figuring out what caused the > problem outlined in > https://sourceforge.net/tracker/?func=detail=614693=1902137_id=96405. > Xalan bundles regexp and bcel, however since one of the recommened ways of > installing xalan is via the endorsed mechanism this will wreak serious havoc > on any other apps that use bcel. That would be less of a problem is xalan's > version were up to date, but as of 2.7.1 it still includes a version from the > early stone age (see XALANJ-2423). The solution is easy: when building the > aggregate jar, add an ant task to rewrite the bundled packages via jarjar > (http://code.google.com/p/jarjar/). This can be trivially added to the build > and creates a completely self-contained xalan jar that will not blow up the > world when endorsed. > I will attach a trivial rule file for jarjar that rewrites the embedded > packages which should immediately fix any collision problems. For more > information about how to use jarjar, see > http://code.google.com/p/jarjar/wiki/GettingStarted -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2436) Xalan must not expose bundled classes (bcel, regexp)
[ https://issues.apache.org/jira/browse/XALANJ-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831585#comment-17831585 ] Joseph Kessselman commented on XALANJ-2436: --- (But note too that the "endorsed" approach should no longer be needed. Sun has shaded their copy of Xalan, and these days most invocations should be through the javax/JAXP/TrAX APIs.) > Xalan must not expose bundled classes (bcel, regexp) > > > Key: XALANJ-2436 > URL: https://issues.apache.org/jira/browse/XALANJ-2436 > Project: XalanJ2 > Issue Type: Bug > Components: Xalan >Affects Versions: 2.7.1 > Environment: any >Reporter: Holger Hoffstätte >Assignee: Joseph Kessselman >Priority: Critical > Attachments: XALAN-2436.patch, rewrite-packages.rules > > > I just spent the better part of half a day figuring out what caused the > problem outlined in > https://sourceforge.net/tracker/?func=detail=614693=1902137_id=96405. > Xalan bundles regexp and bcel, however since one of the recommened ways of > installing xalan is via the endorsed mechanism this will wreak serious havoc > on any other apps that use bcel. That would be less of a problem is xalan's > version were up to date, but as of 2.7.1 it still includes a version from the > early stone age (see XALANJ-2423). The solution is easy: when building the > aggregate jar, add an ant task to rewrite the bundled packages via jarjar > (http://code.google.com/p/jarjar/). This can be trivially added to the build > and creates a completely self-contained xalan jar that will not blow up the > world when endorsed. > I will attach a trivial rule file for jarjar that rewrites the embedded > packages which should immediately fix any collision problems. For more > information about how to use jarjar, see > http://code.google.com/p/jarjar/wiki/GettingStarted -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Assigned] (XALANJ-2436) Xalan must not expose bundled classes (bcel, regexp)
[ https://issues.apache.org/jira/browse/XALANJ-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman reassigned XALANJ-2436: - Assignee: Joseph Kessselman > Xalan must not expose bundled classes (bcel, regexp) > > > Key: XALANJ-2436 > URL: https://issues.apache.org/jira/browse/XALANJ-2436 > Project: XalanJ2 > Issue Type: Bug > Components: Xalan >Affects Versions: 2.7.1 > Environment: any >Reporter: Holger Hoffstätte >Assignee: Joseph Kessselman >Priority: Critical > Attachments: XALAN-2436.patch, rewrite-packages.rules > > > I just spent the better part of half a day figuring out what caused the > problem outlined in > https://sourceforge.net/tracker/?func=detail=614693=1902137_id=96405. > Xalan bundles regexp and bcel, however since one of the recommened ways of > installing xalan is via the endorsed mechanism this will wreak serious havoc > on any other apps that use bcel. That would be less of a problem is xalan's > version were up to date, but as of 2.7.1 it still includes a version from the > early stone age (see XALANJ-2423). The solution is easy: when building the > aggregate jar, add an ant task to rewrite the bundled packages via jarjar > (http://code.google.com/p/jarjar/). This can be trivially added to the build > and creates a completely self-contained xalan jar that will not blow up the > world when endorsed. > I will attach a trivial rule file for jarjar that rewrites the embedded > packages which should immediately fix any collision problems. For more > information about how to use jarjar, see > http://code.google.com/p/jarjar/wiki/GettingStarted -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2436) Xalan must not expose bundled classes (bcel, regexp)
[ https://issues.apache.org/jira/browse/XALANJ-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831584#comment-17831584 ] Joseph Kessselman commented on XALANJ-2436: --- The maven build should be "shading" the internal copy of these into a new package name. It doesn't actually seem to be doing so. I'll check on that > Xalan must not expose bundled classes (bcel, regexp) > > > Key: XALANJ-2436 > URL: https://issues.apache.org/jira/browse/XALANJ-2436 > Project: XalanJ2 > Issue Type: Bug > Components: Xalan >Affects Versions: 2.7.1 > Environment: any >Reporter: Holger Hoffstätte >Priority: Critical > Attachments: XALAN-2436.patch, rewrite-packages.rules > > > I just spent the better part of half a day figuring out what caused the > problem outlined in > https://sourceforge.net/tracker/?func=detail=614693=1902137_id=96405. > Xalan bundles regexp and bcel, however since one of the recommened ways of > installing xalan is via the endorsed mechanism this will wreak serious havoc > on any other apps that use bcel. That would be less of a problem is xalan's > version were up to date, but as of 2.7.1 it still includes a version from the > early stone age (see XALANJ-2423). The solution is easy: when building the > aggregate jar, add an ant task to rewrite the bundled packages via jarjar > (http://code.google.com/p/jarjar/). This can be trivially added to the build > and creates a completely self-contained xalan jar that will not blow up the > world when endorsed. > I will attach a trivial rule file for jarjar that rewrites the embedded > packages which should immediately fix any collision problems. For more > information about how to use jarjar, see > http://code.google.com/p/jarjar/wiki/GettingStarted -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2614) Serializer 2.7.2 / Xalan 2.7.2 - Bug using Mime-Encoding 'ISO-8859-1'
[
https://issues.apache.org/jira/browse/XALANJ-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Kessselman resolved XALANJ-2614.
---
Assignee: Joseph Kessselman (was: Steven J. Hathaway)
Resolution: Fixed
> Serializer 2.7.2 / Xalan 2.7.2 - Bug using Mime-Encoding 'ISO-8859-1'
> -
>
> Key: XALANJ-2614
> URL: https://issues.apache.org/jira/browse/XALANJ-2614
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Serialization
>Affects Versions: 2.7.2
> Environment: Windows 10, Linux
> Java 9, Java 10
>Reporter: Jens Annighöfer
>Assignee: Joseph Kessselman
>Priority: Critical
> Fix For: The Latest Development Code
>
> Attachments: test.zip
>
>
> We found a problem using Xalan / Serializer with Java 9 and 10 when
> transforming an XML document with a styleheet containing an output-encoding.
> {code:xml|title=Simple input|borderStyle=solid}
>
>
> This is a test input.
>
> {code}
> {code:xml|title=Simple stylesheet containing an
> output-encoding|borderStyle=solid}
>
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform; >
>
>
> Tramsformed text:
>
>
>
> {code}
> {code:java|title=Simple transformation code|borderStyle=solid}
> @Test
> public void test2() throws Exception {
> final InputStream is1 =
> Java9Test.class.getClassLoader().getResourceAsStream("test/Input.xml");
> assertNotNull(is1);
> final Document input =
> DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is1);
> assertNotNull(input);
> final InputStream is2 =
> Java9Test.class.getClassLoader().getResourceAsStream("test/Transform.xsl");
> assertNotNull(is2);
> final OutputStream os = new FileOutputStream("Output-" +
> System.getProperty("java.version") + ".txt", false);
> StreamSource xsl = new StreamSource(is2);
> Transformer t = TransformerFactory.newInstance().newTransformer(xsl);
> DOMSource src = new DOMSource(input);
> t.transform(src, new StreamResult(os));
> }
> {code}
> Using Java 7 or Java 8 the result is correct: \{{Tramsformed text: This is a
> test input.}}. Using Java 9 or Java 10 the result is not correct:
> {noformat}
> {noformat}
> indicating an invalid or unknown encoding.
> In Java 7 or Java 8
> _org.apache.xml.serializer.Encodings.getEncodingInfo("ISO-8859-1")_ returns
> "ISO8859_1" which is a valid Java encoding name. In Java 9 oder Java 10 the
> method returns "8859-1" which is not a valid name.
> The problem is caused by a change to the method _keys()_ in the
> _java.util.Properties_ class. This method returns die entries of the
> _Encodings.properties_ in a different order since Java 9.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2614) Serializer 2.7.2 / Xalan 2.7.2 - Bug using Mime-Encoding 'ISO-8859-1'
[
https://issues.apache.org/jira/browse/XALANJ-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831581#comment-17831581
]
Joseph Kessselman commented on XALANJ-2614:
---
With current Xalan Master branch the provided test now passes, running on
openjdk 17.0.8 2023-07-18
OpenJDK Runtime Environment (Red_Hat-17.0.8.0.7-1.fc37) (build 17.0.8+7)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.8.0.7-1.fc37) (build 17.0.8+7, mixed
mode, sharing)
We could add a regression test for this. Perhaps should. But I think the issue
can be considered resolved as of next release.
> Serializer 2.7.2 / Xalan 2.7.2 - Bug using Mime-Encoding 'ISO-8859-1'
> -
>
> Key: XALANJ-2614
> URL: https://issues.apache.org/jira/browse/XALANJ-2614
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Serialization
>Affects Versions: 2.7.2
> Environment: Windows 10, Linux
> Java 9, Java 10
>Reporter: Jens Annighöfer
>Assignee: Steven J. Hathaway
>Priority: Critical
> Fix For: The Latest Development Code
>
> Attachments: test.zip
>
>
> We found a problem using Xalan / Serializer with Java 9 and 10 when
> transforming an XML document with a styleheet containing an output-encoding.
> {code:xml|title=Simple input|borderStyle=solid}
>
>
> This is a test input.
>
> {code}
> {code:xml|title=Simple stylesheet containing an
> output-encoding|borderStyle=solid}
>
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform; >
>
>
> Tramsformed text:
>
>
>
> {code}
> {code:java|title=Simple transformation code|borderStyle=solid}
> @Test
> public void test2() throws Exception {
> final InputStream is1 =
> Java9Test.class.getClassLoader().getResourceAsStream("test/Input.xml");
> assertNotNull(is1);
> final Document input =
> DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is1);
> assertNotNull(input);
> final InputStream is2 =
> Java9Test.class.getClassLoader().getResourceAsStream("test/Transform.xsl");
> assertNotNull(is2);
> final OutputStream os = new FileOutputStream("Output-" +
> System.getProperty("java.version") + ".txt", false);
> StreamSource xsl = new StreamSource(is2);
> Transformer t = TransformerFactory.newInstance().newTransformer(xsl);
> DOMSource src = new DOMSource(input);
> t.transform(src, new StreamResult(os));
> }
> {code}
> Using Java 7 or Java 8 the result is correct: \{{Tramsformed text: This is a
> test input.}}. Using Java 9 or Java 10 the result is not correct:
> {noformat}
> {noformat}
> indicating an invalid or unknown encoding.
> In Java 7 or Java 8
> _org.apache.xml.serializer.Encodings.getEncodingInfo("ISO-8859-1")_ returns
> "ISO8859_1" which is a valid Java encoding name. In Java 9 oder Java 10 the
> method returns "8859-1" which is not a valid name.
> The problem is caused by a change to the method _keys()_ in the
> _java.util.Properties_ class. This method returns die entries of the
> _Encodings.properties_ in a different order since Java 9.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2614) Serializer 2.7.2 / Xalan 2.7.2 - Bug using Mime-Encoding 'ISO-8859-1'
[
https://issues.apache.org/jira/browse/XALANJ-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17831577#comment-17831577
]
Joseph Kessselman commented on XALANJ-2614:
---
I think this one may have been fixed, since we changed the encoding lookup to
work more reliably in both directions. It should be easy to test whether that's
true.
> Serializer 2.7.2 / Xalan 2.7.2 - Bug using Mime-Encoding 'ISO-8859-1'
> -
>
> Key: XALANJ-2614
> URL: https://issues.apache.org/jira/browse/XALANJ-2614
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Serialization
>Affects Versions: 2.7.2
> Environment: Windows 10, Linux
> Java 9, Java 10
>Reporter: Jens Annighöfer
>Assignee: Steven J. Hathaway
>Priority: Critical
> Fix For: The Latest Development Code
>
> Attachments: test.zip
>
>
> We found a problem using Xalan / Serializer with Java 9 and 10 when
> transforming an XML document with a styleheet containing an output-encoding.
> {code:xml|title=Simple input|borderStyle=solid}
>
>
> This is a test input.
>
> {code}
> {code:xml|title=Simple stylesheet containing an
> output-encoding|borderStyle=solid}
>
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform; >
>
>
> Tramsformed text:
>
>
>
> {code}
> {code:java|title=Simple transformation code|borderStyle=solid}
> @Test
> public void test2() throws Exception {
> final InputStream is1 =
> Java9Test.class.getClassLoader().getResourceAsStream("test/Input.xml");
> assertNotNull(is1);
> final Document input =
> DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(is1);
> assertNotNull(input);
> final InputStream is2 =
> Java9Test.class.getClassLoader().getResourceAsStream("test/Transform.xsl");
> assertNotNull(is2);
> final OutputStream os = new FileOutputStream("Output-" +
> System.getProperty("java.version") + ".txt", false);
> StreamSource xsl = new StreamSource(is2);
> Transformer t = TransformerFactory.newInstance().newTransformer(xsl);
> DOMSource src = new DOMSource(input);
> t.transform(src, new StreamResult(os));
> }
> {code}
> Using Java 7 or Java 8 the result is correct: \{{Tramsformed text: This is a
> test input.}}. Using Java 9 or Java 10 the result is not correct:
> {noformat}
> {noformat}
> indicating an invalid or unknown encoding.
> In Java 7 or Java 8
> _org.apache.xml.serializer.Encodings.getEncodingInfo("ISO-8859-1")_ returns
> "ISO8859_1" which is a valid Java encoding name. In Java 9 oder Java 10 the
> method returns "8859-1" which is not a valid name.
> The problem is caused by a change to the method _keys()_ in the
> _java.util.Properties_ class. This method returns die entries of the
> _Encodings.properties_ in a different order since Java 9.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-1324) XSLTC compiltation error : Branch target offset too large for short
[ https://issues.apache.org/jira/browse/XALANJ-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman resolved XALANJ-1324. --- Resolution: Fixed > XSLTC compiltation error : Branch target offset too large for short > --- > > Key: XALANJ-1324 > URL: https://issues.apache.org/jira/browse/XALANJ-1324 > Project: XalanJ2 > Issue Type: Bug > Components: XSLTC >Affects Versions: 2.7 > Environment: Operating System: Solaris > Platform: Sun >Reporter: R Sumathi >Assignee: Joseph Kessselman >Priority: Blocker > Fix For: 2.7.1 > > Attachments: ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, > ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, > ASF.LICENSE.NOT.GRANTED--transform.java, j1324.patch.txt > > > When I am trying to compile a complex style sheet, I am getting the following > error. > Compiler error(s): > Branch target offset too large for short > Without changing the XSL how to compile it? > Is there any solution for this? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Reopened] (XALANJ-1324) XSLTC compiltation error : Branch target offset too large for short
[ https://issues.apache.org/jira/browse/XALANJ-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman reopened XALANJ-1324: --- Assignee: Joseph Kessselman (was: Henry Zongaro) > XSLTC compiltation error : Branch target offset too large for short > --- > > Key: XALANJ-1324 > URL: https://issues.apache.org/jira/browse/XALANJ-1324 > Project: XalanJ2 > Issue Type: Bug > Components: XSLTC >Affects Versions: 2.7 > Environment: Operating System: Solaris > Platform: Sun >Reporter: R Sumathi >Assignee: Joseph Kessselman >Priority: Blocker > Fix For: 2.7.1 > > Attachments: ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, > ASF.LICENSE.NOT.GRANTED--Satelindo-SS.xsl, > ASF.LICENSE.NOT.GRANTED--transform.java, j1324.patch.txt > > > When I am trying to compile a complex style sheet, I am getting the following > error. > Compiler error(s): > Branch target offset too large for short > Without changing the XSL how to compile it? > Is there any solution for this? -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
[ https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830871#comment-17830871 ] Mukul Gandhi commented on XALANJ-2734: -- (1) OK. I was just suggesting this because it would give us a clean way to get the XSLT 3.0 subset out in front of the public, and maintained as part of the standard Xalan product, rather than having it be off in a separate build. It would also avoid having to keep two branches in synch on an ongoing basis. [mukul] Following is another idea, to handle this, We may have two Xalan codebases parallel to each other on dev repos branch 'master', and only one build shall handle those (the current maven build on dev repos branch 'master', needs to be modified to handle Xalan XSLT 3.0 work as well from dev branch xalan-j_xslt3.0). With this, a single Xalan build on branch 'master', shall produce two Xalan jars. One will be for XSLT 1.0, and other shall be for XSLT 3.0 subset. (2) I'm less certain about merging it into Xalan as it stands, bound to the default namespace. [mukul] I think, that we should not change Xalan implementation of following (that's specified within XSLT stylesheets) for Xalan's XSLT 3.0 subset work, http://www.w3.org/1999/XSL/Transform; ... This shall be less of a problem, when Xalan's XSLT 3.0 subset work gets built along with 1.0 work from Xalan's branch 'master'. > Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? > --- > > Key: XALANJ-2734 > URL: https://issues.apache.org/jira/browse/XALANJ-2734 > Project: XalanJ2 > Issue Type: Wish > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Joseph Kessselman >Assignee: Mukul Gandhi >Priority: Major > > There has been work in progress (thanks, Mukul) to create a version of Xalan > extended with some features from XSLT 3.0, and perhaps 3.1. > My understanding (which may be wrong) is that to date this work has been done > by directly adding the new functionality to core Xalan, within the default > XSLT namespaces. > A better solution, where possible, might be to treat these as Xalan > extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html > |http://example.com]. > The details of coding these can be found at > [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] > That would put the new functions and elements in a Xalan-specific namespace > from XSLT 2.0, requiring that they be prefixed when invoked and that these > namespaces be declared before accessing them. Yes, it's less pretty, but it > makes the portability issue explicit. It also makes clearer that the new > functionality may not be available in compiled mode yet, and provides some > templates for implementing the latter. > Note that extensions can implement elements as well as functions. I would > argue that if there is a 3.0 change to an element's behavior, we should > create an extension element to provide that behavior, even if it is largely a > copy of or a wrapper of our 2.0 implementation, to make the new behavior > available only when explicitly referenced as an extension. That limits any > risk of conflict between old and new definitions. > There is the question of what namespace to use for these. I can see arguments > both for keeping them in a Xalan-defined namespace, and for using the > XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict > compliance of these functions/elements with the W3C Recommendations before > presuming to use W3C's namespaces for them, so I'd lean toward keeping them > in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions > on this. > With that clear division between what is part of a compatible XSLT 2.0 > implementations and what is not, I'd be willing to consider releasing the new > features as part of Xalan, clearly documented as not representing a full 3.0 > implementation... much the way we added implementations of EXSLT to the > system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and > demonstrates how to make them work with Xalan. > Ideally, there would be minimal change needed to the base Xalan code, thus > minimizing risk of regression unless the extentions are being used. If deeper > modifications to the data or processing model are required, we might not want > to include those in our product stream until we are willing to properly > consider upgrading the whole engine to a recent version of the W3C &g
[jira] [Assigned] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman reassigned XALANJ-2650: - Assignee: Joseph Kessselman (was: Gary D. Gregory) > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Joseph Kessselman >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830775#comment-17830775 ] Joseph Kessselman commented on XALANJ-2650: --- Re META-INF/services: See [https://stackoverflow.com/questions/17531625/how-to-include-a-config-file-in-the-meta-inf-services-folder-of-a-jar-using-ma|http://example.com] According to that discussion, the fix is to move META-INF/services from src/main/java to src/main/resources. Testing appears to confirm that. Change being checked in. Please confirm. *NOTE:* This META-INF/services mechanism apparently gets phased out after Java 8, in favor of a module-info.java file. But since we still support building and running on Java 8, I suspect we may wind up wanting to implement both. > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Resolved] (XALANJ-2370) java_cup - duplicate classes in classpath
[ https://issues.apache.org/jira/browse/XALANJ-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman resolved XALANJ-2370. --- Resolution: Fixed > java_cup - duplicate classes in classpath > - > > Key: XALANJ-2370 > URL: https://issues.apache.org/jira/browse/XALANJ-2370 > Project: XalanJ2 > Issue Type: Bug > Components: Xalan, XSLTC >Affects Versions: 2.7.1 >Reporter: Thomas Spiegl >Priority: Blocker > > xalan.jar contains java cup classes http://www2.cs.tum.edu/projects/cup/ > without changing the namespace (package name). This leads to duplicate class > problems, if someone is using a different cup version in his project. > Just stumbled on this issue as my generated parser did not compile, because > my IDE loaded xalan's cup classes first. > I can work around this issue by refactoring cup classes by myself. But this > should only be a temporary solution. > To be done: refactor cup package names when delivering with xalan.jar > Thanks! > Thomas -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650 ] Joseph Kessselman deleted comment on XALANJ-2650: --- was (Author: jkesselm): "The Bundle-License header provides an optional machine readable form of license information." > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830713#comment-17830713
]
Joseph Kessselman commented on XALANJ-2731:
---
I've checked in a changeset which I believe addresses this. Please confirm that
the current master/head code, when built, produces the desired results.
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830711#comment-17830711 ] Joseph Kessselman commented on XALANJ-2650: --- Checked in changes. Please confirm that building the current master/HEAD code with maven addresses the reported issues. > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830709#comment-17830709 ] Joseph Kessselman commented on XALANJ-2650: --- Adding that to the Maven build's top-level pom.xml apparently adds META-INF/LICENSE to the jarfiles automagically. > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830706#comment-17830706 ] Joseph Kessselman commented on XALANJ-2650: --- Apache parent POM: We haven't been. I can add that to the Maven build. > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830704#comment-17830704 ] Joseph Kessselman commented on XALANJ-2650: --- "The Bundle-License header provides an optional machine readable form of license information." > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830691#comment-17830691 ] Gary D. Gregory commented on XALANJ-2650: - We should really be using the Apache parent POM if we are not already. > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830688#comment-17830688 ] Joseph Kessselman commented on XALANJ-2650: --- As far as I can tell, it is not mandatory that a Maven project have a parent POM, if it is self-contained. > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Updated] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
[ https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman updated XALANJ-2734: -- Issue Type: Wish (was: Bug) > Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? > --- > > Key: XALANJ-2734 > URL: https://issues.apache.org/jira/browse/XALANJ-2734 > Project: XalanJ2 > Issue Type: Wish > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Joseph Kessselman >Assignee: Mukul Gandhi >Priority: Major > > There has been work in progress (thanks, Mukul) to create a version of Xalan > extended with some features from XSLT 3.0, and perhaps 3.1. > My understanding (which may be wrong) is that to date this work has been done > by directly adding the new functionality to core Xalan, within the default > XSLT namespaces. > A better solution, where possible, might be to treat these as Xalan > extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html > |http://example.com]. > The details of coding these can be found at > [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] > That would put the new functions and elements in a Xalan-specific namespace > from XSLT 2.0, requiring that they be prefixed when invoked and that these > namespaces be declared before accessing them. Yes, it's less pretty, but it > makes the portability issue explicit. It also makes clearer that the new > functionality may not be available in compiled mode yet, and provides some > templates for implementing the latter. > Note that extensions can implement elements as well as functions. I would > argue that if there is a 3.0 change to an element's behavior, we should > create an extension element to provide that behavior, even if it is largely a > copy of or a wrapper of our 2.0 implementation, to make the new behavior > available only when explicitly referenced as an extension. That limits any > risk of conflict between old and new definitions. > There is the question of what namespace to use for these. I can see arguments > both for keeping them in a Xalan-defined namespace, and for using the > XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict > compliance of these functions/elements with the W3C Recommendations before > presuming to use W3C's namespaces for them, so I'd lean toward keeping them > in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions > on this. > With that clear division between what is part of a compatible XSLT 2.0 > implementations and what is not, I'd be willing to consider releasing the new > features as part of Xalan, clearly documented as not representing a full 3.0 > implementation... much the way we added implementations of EXSLT to the > system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and > demonstrates how to make them work with Xalan. > Ideally, there would be minimal change needed to the base Xalan code, thus > minimizing risk of regression unless the extentions are being used. If deeper > modifications to the data or processing model are required, we might not want > to include those in our product stream until we are willing to properly > consider upgrading the whole engine to a recent version of the W3C > standards... which, if our experience moving from 1.0 to 2.0 was any > indication, involves a much larger and more systematic reconsideration of the > entire architecture's base assumptions. > I'd sorta like to stop having a completely separate branch for the 3.0 > experiments. Making them part of the Xalan Extensions Library is the best > idea I have for bringing them into the main branch any time soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
[ https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830617#comment-17830617 ] Joseph Kessselman edited comment on XALANJ-2734 at 3/25/24 5:49 PM: OK. I was just suggesting this because it would give us a clean way to get the XSLT 3.0 subset out in front of the public, and maintained as part of the standard Xalan product, rather than having it be off in a separate build. It would also avoid having to keep two branches in synch on an ongoing basis. I'm less certain about merging it into Xalan as it stands, bound to the default namespace. Doesn't have to be resolved right now. I just wanted to bring it up since I think we're close to trusting the Maven-based build enough to release that, and then to hopefully start doing more frequent releases as fixes get applied. Feel free to close this request as "won't do", if you wish. was (Author: jkesselm): OK. I was just suggesting this because it would give us a clean way to get the XSLT 3.0 subset out in front of the public, and maintained, as part of the standard Xalan product rather than having it be off in a separate build. It would also avoid having to keep two branches in synch on an ongoing basis. I'm less certain about merging it into Xalan as it stands, bound to the default namespace. Doesn't have to be resolved right now. I just wanted to bring it up since I think we're close to trusting the Maven-based build enough to release that, and then to hopefully start doing more frequent releases as fixes get applied. Feel free to close this request as "won't do", if you wish. > Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? > --- > > Key: XALANJ-2734 > URL: https://issues.apache.org/jira/browse/XALANJ-2734 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Joseph Kessselman >Assignee: Mukul Gandhi >Priority: Major > > There has been work in progress (thanks, Mukul) to create a version of Xalan > extended with some features from XSLT 3.0, and perhaps 3.1. > My understanding (which may be wrong) is that to date this work has been done > by directly adding the new functionality to core Xalan, within the default > XSLT namespaces. > A better solution, where possible, might be to treat these as Xalan > extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html > |http://example.com]. > The details of coding these can be found at > [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] > That would put the new functions and elements in a Xalan-specific namespace > from XSLT 2.0, requiring that they be prefixed when invoked and that these > namespaces be declared before accessing them. Yes, it's less pretty, but it > makes the portability issue explicit. It also makes clearer that the new > functionality may not be available in compiled mode yet, and provides some > templates for implementing the latter. > Note that extensions can implement elements as well as functions. I would > argue that if there is a 3.0 change to an element's behavior, we should > create an extension element to provide that behavior, even if it is largely a > copy of or a wrapper of our 2.0 implementation, to make the new behavior > available only when explicitly referenced as an extension. That limits any > risk of conflict between old and new definitions. > There is the question of what namespace to use for these. I can see arguments > both for keeping them in a Xalan-defined namespace, and for using the > XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict > compliance of these functions/elements with the W3C Recommendations before > presuming to use W3C's namespaces for them, so I'd lean toward keeping them > in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions > on this. > With that clear division between what is part of a compatible XSLT 2.0 > implementations and what is not, I'd be willing to consider releasing the new > features as part of Xalan, clearly documented as not representing a full 3.0 > implementation... much the way we added implementations of EXSLT to the > system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and > demonstrates how to make them work with Xalan. > Ideally, there would be minimal change needed to the base Xalan code, thus > minimizing risk of regression unless
[jira] [Commented] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
[ https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830617#comment-17830617 ] Joseph Kessselman commented on XALANJ-2734: --- OK. I was just suggesting this because it would give us a clean way to get the XSLT 3.0 subset out in front of the public, and maintained, as part of the standard Xalan product rather than having it be off in a separate build. It would also avoid having to keep two branches in synch on an ongoing basis. I'm less certain about merging it into Xalan as it stands, bound to the default namespace. Doesn't have to be resolved right now. I just wanted to bring it up since I think we're close to trusting the Maven-based build enough to release that, and then to hopefully start doing more frequent releases as fixes get applied. > Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? > --- > > Key: XALANJ-2734 > URL: https://issues.apache.org/jira/browse/XALANJ-2734 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Joseph Kessselman >Assignee: Mukul Gandhi >Priority: Major > > There has been work in progress (thanks, Mukul) to create a version of Xalan > extended with some features from XSLT 3.0, and perhaps 3.1. > My understanding (which may be wrong) is that to date this work has been done > by directly adding the new functionality to core Xalan, within the default > XSLT namespaces. > A better solution, where possible, might be to treat these as Xalan > extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html > |http://example.com]. > The details of coding these can be found at > [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] > That would put the new functions and elements in a Xalan-specific namespace > from XSLT 2.0, requiring that they be prefixed when invoked and that these > namespaces be declared before accessing them. Yes, it's less pretty, but it > makes the portability issue explicit. It also makes clearer that the new > functionality may not be available in compiled mode yet, and provides some > templates for implementing the latter. > Note that extensions can implement elements as well as functions. I would > argue that if there is a 3.0 change to an element's behavior, we should > create an extension element to provide that behavior, even if it is largely a > copy of or a wrapper of our 2.0 implementation, to make the new behavior > available only when explicitly referenced as an extension. That limits any > risk of conflict between old and new definitions. > There is the question of what namespace to use for these. I can see arguments > both for keeping them in a Xalan-defined namespace, and for using the > XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict > compliance of these functions/elements with the W3C Recommendations before > presuming to use W3C's namespaces for them, so I'd lean toward keeping them > in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions > on this. > With that clear division between what is part of a compatible XSLT 2.0 > implementations and what is not, I'd be willing to consider releasing the new > features as part of Xalan, clearly documented as not representing a full 3.0 > implementation... much the way we added implementations of EXSLT to the > system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and > demonstrates how to make them work with Xalan. > Ideally, there would be minimal change needed to the base Xalan code, thus > minimizing risk of regression unless the extentions are being used. If deeper > modifications to the data or processing model are required, we might not want > to include those in our product stream until we are willing to properly > consider upgrading the whole engine to a recent version of the W3C > standards... which, if our experience moving from 1.0 to 2.0 was any > indication, involves a much larger and more systematic reconsideration of the > entire architecture's base assumptions. > I'd sorta like to stop having a completely separate branch for the 3.0 > experiments. Making them part of the Xalan Extensions Library is the best > idea I have for bringing them into the main branch any time soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
[ https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830617#comment-17830617 ] Joseph Kessselman edited comment on XALANJ-2734 at 3/25/24 5:42 PM: OK. I was just suggesting this because it would give us a clean way to get the XSLT 3.0 subset out in front of the public, and maintained, as part of the standard Xalan product rather than having it be off in a separate build. It would also avoid having to keep two branches in synch on an ongoing basis. I'm less certain about merging it into Xalan as it stands, bound to the default namespace. Doesn't have to be resolved right now. I just wanted to bring it up since I think we're close to trusting the Maven-based build enough to release that, and then to hopefully start doing more frequent releases as fixes get applied. Feel free to close this request as "won't do", if you wish. was (Author: jkesselm): OK. I was just suggesting this because it would give us a clean way to get the XSLT 3.0 subset out in front of the public, and maintained, as part of the standard Xalan product rather than having it be off in a separate build. It would also avoid having to keep two branches in synch on an ongoing basis. I'm less certain about merging it into Xalan as it stands, bound to the default namespace. Doesn't have to be resolved right now. I just wanted to bring it up since I think we're close to trusting the Maven-based build enough to release that, and then to hopefully start doing more frequent releases as fixes get applied. > Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? > --- > > Key: XALANJ-2734 > URL: https://issues.apache.org/jira/browse/XALANJ-2734 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Joseph Kessselman >Assignee: Mukul Gandhi >Priority: Major > > There has been work in progress (thanks, Mukul) to create a version of Xalan > extended with some features from XSLT 3.0, and perhaps 3.1. > My understanding (which may be wrong) is that to date this work has been done > by directly adding the new functionality to core Xalan, within the default > XSLT namespaces. > A better solution, where possible, might be to treat these as Xalan > extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html > |http://example.com]. > The details of coding these can be found at > [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] > That would put the new functions and elements in a Xalan-specific namespace > from XSLT 2.0, requiring that they be prefixed when invoked and that these > namespaces be declared before accessing them. Yes, it's less pretty, but it > makes the portability issue explicit. It also makes clearer that the new > functionality may not be available in compiled mode yet, and provides some > templates for implementing the latter. > Note that extensions can implement elements as well as functions. I would > argue that if there is a 3.0 change to an element's behavior, we should > create an extension element to provide that behavior, even if it is largely a > copy of or a wrapper of our 2.0 implementation, to make the new behavior > available only when explicitly referenced as an extension. That limits any > risk of conflict between old and new definitions. > There is the question of what namespace to use for these. I can see arguments > both for keeping them in a Xalan-defined namespace, and for using the > XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict > compliance of these functions/elements with the W3C Recommendations before > presuming to use W3C's namespaces for them, so I'd lean toward keeping them > in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions > on this. > With that clear division between what is part of a compatible XSLT 2.0 > implementations and what is not, I'd be willing to consider releasing the new > features as part of Xalan, clearly documented as not representing a full 3.0 > implementation... much the way we added implementations of EXSLT to the > system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and > demonstrates how to make them work with Xalan. > Ideally, there would be minimal change needed to the base Xalan code, thus > minimizing risk of regression unless the extentions are being used. If deeper > modifications to the
[jira] [Commented] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
[ https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830540#comment-17830540 ] Mukul Gandhi commented on XALANJ-2734: -- [~jkesselm], I think Xalan extension mechanism to create custom XSLT extension elements is a nice feature provided by Xalan. I believe that, Xalan extension element feature, should be used to implement extension elements that're not part of XSLT specification. What you're suggesting within this jira issue, is to redo all the XSLT 3 implementation code we've written on the Xalan dev repos branch xalan-j_xslt3.0 and convert those XSLT 3 native element implementations into Xalan extension elements. IMHO, but this doesn't look right to me :(, since we've already implemented many XSLT 3 instructions natively, which is lot of new XSLT 3 compliant code (we've already spent it seems about nearly one year of work effort on this) we've written on the dev repos branch xalan-j_xslt3.0. When we started work on Xalan's XSLT 3.0 implementation on dev repos branch xalan-j_xslt3.0, we decided with consensus to try implementing a compliant XSLT 3.0 processor for Xalan. Had we been in the situation, when the amount of implementation code was less and the implementation was not stable (we're not yet much compliant to the relevant XPath spec for Xalan's XSLT 3 implementation, but for XSLT instructions newly introduced within 3.0 spec Xalan's compliance is nice), we could have discarded that and could have restarted implementing those as Xalan extension elements. > Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? > --- > > Key: XALANJ-2734 > URL: https://issues.apache.org/jira/browse/XALANJ-2734 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Joseph Kessselman >Assignee: Mukul Gandhi >Priority: Major > > There has been work in progress (thanks, Mukul) to create a version of Xalan > extended with some features from XSLT 3.0, and perhaps 3.1. > My understanding (which may be wrong) is that to date this work has been done > by directly adding the new functionality to core Xalan, within the default > XSLT namespaces. > A better solution, where possible, might be to treat these as Xalan > extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html > |http://example.com]. > The details of coding these can be found at > [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] > That would put the new functions and elements in a Xalan-specific namespace > from XSLT 2.0, requiring that they be prefixed when invoked and that these > namespaces be declared before accessing them. Yes, it's less pretty, but it > makes the portability issue explicit. It also makes clearer that the new > functionality may not be available in compiled mode yet, and provides some > templates for implementing the latter. > Note that extensions can implement elements as well as functions. I would > argue that if there is a 3.0 change to an element's behavior, we should > create an extension element to provide that behavior, even if it is largely a > copy of or a wrapper of our 2.0 implementation, to make the new behavior > available only when explicitly referenced as an extension. That limits any > risk of conflict between old and new definitions. > There is the question of what namespace to use for these. I can see arguments > both for keeping them in a Xalan-defined namespace, and for using the > XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict > compliance of these functions/elements with the W3C Recommendations before > presuming to use W3C's namespaces for them, so I'd lean toward keeping them > in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions > on this. > With that clear division between what is part of a compatible XSLT 2.0 > implementations and what is not, I'd be willing to consider releasing the new > features as part of Xalan, clearly documented as not representing a full 3.0 > implementation... much the way we added implementations of EXSLT to the > system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and > demonstrates how to make them work with Xalan. > Ideally, there would be minimal change needed to the base Xalan code, thus > minimizing risk of regression unless the extentions are being used. If deeper > modifications to the data or processing model are required, we might
[jira] [Assigned] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
[ https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman reassigned XALANJ-2734: - Assignee: Mukul Gandhi > Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? > --- > > Key: XALANJ-2734 > URL: https://issues.apache.org/jira/browse/XALANJ-2734 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Joseph Kessselman >Assignee: Mukul Gandhi >Priority: Major > > There has been work in progress (thanks, Mukul) to create a version of Xalan > extended with some features from XSLT 3.0, and perhaps 3.1. > My understanding (which may be wrong) is that to date this work has been done > by directly adding the new functionality to core Xalan, within the default > XSLT namespaces. > A better solution, where possible, might be to treat these as Xalan > extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html > |http://example.com]. > The details of coding these can be found at > [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] > That would put the new functions and elements in a Xalan-specific namespace > from XSLT 2.0, requiring that they be prefixed when invoked and that these > namespaces be declared before accessing them. Yes, it's less pretty, but it > makes the portability issue explicit. It also makes clearer that the new > functionality may not be available in compiled mode yet, and provides some > templates for implementing the latter. > Note that extensions can implement elements as well as functions. I would > argue that if there is a 3.0 change to an element's behavior, we should > create an extension element to provide that behavior, even if it is largely a > copy of or a wrapper of our 2.0 implementation, to make the new behavior > available only when explicitly referenced as an extension. That limits any > risk of conflict between old and new definitions. > There is the question of what namespace to use for these. I can see arguments > both for keeping them in a Xalan-defined namespace, and for using the > XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict > compliance of these functions/elements with the W3C Recommendations before > presuming to use W3C's namespaces for them, so I'd lean toward keeping them > in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions > on this. > With that clear division between what is part of a compatible XSLT 2.0 > implementations and what is not, I'd be willing to consider releasing the new > features as part of Xalan, clearly documented as not representing a full 3.0 > implementation... much the way we added implementations of EXSLT to the > system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and > demonstrates how to make them work with Xalan. > Ideally, there would be minimal change needed to the base Xalan code, thus > minimizing risk of regression unless the extentions are being used. If deeper > modifications to the data or processing model are required, we might not want > to include those in our product stream until we are willing to properly > consider upgrading the whole engine to a recent version of the W3C > standards... which, if our experience moving from 1.0 to 2.0 was any > indication, involves a much larger and more systematic reconsideration of the > entire architecture's base assumptions. > I'd sorta like to stop having a completely separate branch for the 3.0 > experiments. Making them part of the Xalan Extensions Library is the best > idea I have for bringing them into the main branch any time soon. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Updated] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
[ https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Kessselman updated XALANJ-2734: -- Description: There has been work in progress (thanks, Mukul) to create a version of Xalan extended with some features from XSLT 3.0, and perhaps 3.1. My understanding (which may be wrong) is that to date this work has been done by directly adding the new functionality to core Xalan, within the default XSLT namespaces. A better solution, where possible, might be to treat these as Xalan extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html |http://example.com]. The details of coding these can be found at [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] That would put the new functions and elements in a Xalan-specific namespace from XSLT 2.0, requiring that they be prefixed when invoked and that these namespaces be declared before accessing them. Yes, it's less pretty, but it makes the portability issue explicit. It also makes clearer that the new functionality may not be available in compiled mode yet, and provides some templates for implementing the latter. Note that extensions can implement elements as well as functions. I would argue that if there is a 3.0 change to an element's behavior, we should create an extension element to provide that behavior, even if it is largely a copy of or a wrapper of our 2.0 implementation, to make the new behavior available only when explicitly referenced as an extension. That limits any risk of conflict between old and new definitions. There is the question of what namespace to use for these. I can see arguments both for keeping them in a Xalan-defined namespace, and for using the XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict compliance of these functions/elements with the W3C Recommendations before presuming to use W3C's namespaces for them, so I'd lean toward keeping them in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions on this. With that clear division between what is part of a compatible XSLT 2.0 implementations and what is not, I'd be willing to consider releasing the new features as part of Xalan, clearly documented as not representing a full 3.0 implementation... much the way we added implementations of EXSLT to the system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and demonstrates how to make them work with Xalan. Ideally, there would be minimal change needed to the base Xalan code, thus minimizing risk of regression unless the extentions are being used. If deeper modifications to the data or processing model are required, we might not want to include those in our product stream until we are willing to properly consider upgrading the whole engine to a recent version of the W3C standards... which, if our experience moving from 1.0 to 2.0 was any indication, involves a much larger and more systematic reconsideration of the entire architecture's base assumptions. I'd sorta like to stop having a completely separate branch for the 3.0 experiments. Making them part of the Xalan Extensions Library is the best idea I have for bringing them into the main branch any time soon. > Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? > --- > > Key: XALANJ-2734 > URL: https://issues.apache.org/jira/browse/XALANJ-2734 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Joseph Kessselman >Priority: Major > > There has been work in progress (thanks, Mukul) to create a version of Xalan > extended with some features from XSLT 3.0, and perhaps 3.1. > My understanding (which may be wrong) is that to date this work has been done > by directly adding the new functionality to core Xalan, within the default > XSLT namespaces. > A better solution, where possible, might be to treat these as Xalan > extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html > |http://example.com]. > The details of coding these can be found at > [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.] > That would put the new functions and elements in a Xalan-specific namespace > from XSLT 2.0, requiring that they be prefixed when invoked and that these > namespaces be declared before accessing them. Yes, it's less pretty, but it > makes the portability issue explicit. It also makes clearer that the new > functionality may not be available in compiled mode yet, and p
[jira] [Created] (XALANJ-2734) Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
Joseph Kessselman created XALANJ-2734: - Summary: Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions? Key: XALANJ-2734 URL: https://issues.apache.org/jira/browse/XALANJ-2734 Project: XalanJ2 Issue Type: Bug Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Reporter: Joseph Kessselman -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANC-743) XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till out of memory
[ https://issues.apache.org/jira/browse/XALANC-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829379#comment-17829379 ] Daehyeon Kim commented on XALANC-743: - This appears to be a very similar issue to the issue reported in XALANJ-2419. If you transform when Unicode supplementary characters is included in the input, the output will be corrupted. I also confirmed that both Xalan-C++ versions 1.10 to 1.12 have the same problem. I fixed this problem. This problem appears for both UTF-16 output encoding and UTF-8 output encoding. When using UTF16Writer, supplementary characters are converted to broken characters such as "??". If you use UTF8Writer you will have a more serious problem where you will not even get broken characters and transform will get no output results. This means there may be a problem at a higher level than serialization, and I found something suspicious in the XPath FunctionSubstring implementation. There is no problem with UTF16Writer and UTF8Writer. XPath FunctionSubstring takes a character index position as an argument. And a surrogate pair needs to be counted as one character (as the XPath Recommendation ([https://www.w3.org/TR/xpath-functions-31/#func-substring])). So we need to count the string buffer positions where the surrogate pair is considered at the character index. But now xalan truncates the string buffer only with the arguments received the character index. This will cause the truncated string to be corrupted when the surrogate pair is in the string buffer. The same goes for this issue. If a string containing supplementary characters is incorrectly truncated in FunstionSubstring, surrogate pairs (which cannot appear in UTF-8) may surprisingly appear in UTF8Writer..(and this can also be seen in the assertion in UTF8Writer "// We should never get a high or low surrogate here..."). So I fixed the XPath FunctionSubstring to count the string data length considering the surrogate pair. Then this issue will be automatically resolved. Please refer to the pull request to see the changed code. > XalanOutputStream::transcode falls into infinite loop on 4 bytes unicode till > out of memory > --- > > Key: XALANC-743 > URL: https://issues.apache.org/jira/browse/XALANC-743 > Project: XalanC > Issue Type: Bug > Components: XalanC >Affects Versions: 1.10 > Environment: Linux >Reporter: Jiangbei Fan >Assignee: Steven J. Hathaway >Priority: Major > > In some rare cases, XalanTransformer::transform would stuck or crash when the > input/stylesheet contains 4-byte unicode. And I traced down the root cause in > XalanOutputStream::transcode > When the transcode buffer contains unicode of size 4 bytes, and the last > XalanDOMChar in the buffer is the first 2 bytes of a 4-byte unicode char. The > XalanOutputStream::transcode will fall into an infinite loop till it is out > of memory. As XMLUTF8Transcoder.cpp in xerces will not consume the last > 2-bytes if it is part of 4 byte unicode. And transcode always loop until all > chars in the buffer is eaten. Specifically this will happen when the last > XalanDOMChar in the input buffer is between 0xD800 and 0xDBFF. > I cannot find whether this issue has been reported before. This is version > 1.10. I do have a fix to add a bool reference to the function, so that the > caller can push the last 2 byte back to the buffer if not consumed. But want > to check it out before submit any fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2733) xalan implementation of function fn:csv-to-xml
Mukul Gandhi created XALANJ-2733: Summary: xalan implementation of function fn:csv-to-xml Key: XALANJ-2733 URL: https://issues.apache.org/jira/browse/XALANJ-2733 Project: XalanJ2 Issue Type: Wish Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Components: XPath-function Reporter: Mukul Gandhi The latest XPath and XQuery F 4.0 w3c editor's draft, specifies definition of function fn:csv-to-xml. I think, its a useful XPath function, and we should perhaps have an implementation of this function similar to this function's definition that is specified within XPath and XQuery F spec, as Xalan extension function. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2591) Transform XSLT using Xalan into XHTML fails with secure processing feature when using attributes
[
https://issues.apache.org/jira/browse/XALANJ-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823809#comment-17823809
]
Joshua Marquart commented on XALANJ-2591:
-
Servicemix Xalan 2.7.3_3 resolves XALANJ-2591
This fix really should be deployed with next Xalan release
> Transform XSLT using Xalan into XHTML fails with secure processing feature
> when using attributes
>
>
> Key: XALANJ-2591
> URL: https://issues.apache.org/jira/browse/XALANJ-2591
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: transformation, Xalan
>Affects Versions: 2.7.2
>Reporter: Victor Kazakov
>Assignee: Steven J. Hathaway
>Priority: Major
> Attachments: XSLTElementProcessor.patch, xalan-test.zip
>
>
> I'm trying to use the updated version of Xalan (2.7.2) in secure mode and
> having issue with it not able to understand unknown attributes. The problem
> is, it prevents you from using any stylesheet that emits XHTML (in secure
> processing mode) because it disallows things like “colspan” attributes of
> “th” elements.
> The associated changed file is here:
> http://svn.apache.org/viewvc/xalan/java/branches/xalan-j_2_7_1_maint/src/org/apache/xalan/processor/XSLTElementProcessor.java?r1=1359736=1581058=1581058_format=h
> See the following example:
> {code:java}
> import javax.xml.XMLConstants;
> import javax.xml.transform.*;
> import javax.xml.transform.stream.StreamSource;
> import java.io.StringReader;
> public class XalanSecureAttributeRepro {
> private static final String XSL =
> " xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\;>\n" +
> " \n" +
> " \n" +
> "\n" +
> " \n" +
> "";
> public static void main( String[] args ) throws Exception {
> System.setProperty( "javax.xml.transform.TransformerFactory",
> "org.apache.xalan.processor.TransformerFactoryImpl" );
> TransformerFactory tf = TransformerFactory.newInstance();
> tf.setFeature( XMLConstants.FEATURE_SECURE_PROCESSING, true);
> tf.setErrorListener( new DefaultErrorHandler( true ) );
> final Source source = new StreamSource( new StringReader( XSL ) );
> Templates templates = tf.newTemplates( source ); // throws:
> // TransformerException: "colspan" attribute is not
> allowed on the th element!
> }
> }
> {code}
> It returns this error:
> {code}
> Exception in thread "main"
> javax.xml.transform.TransformerConfigurationException:
> javax.xml.transform.TransformerException: org.xml.sax.SAXException: "colspan"
> attribute is not allowed on the th element!
> javax.xml.transform.TransformerException: "colspan" attribute is not allowed
> on the th element!
> at
> org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:933)
> at
> com.l7tech.example.XalanSecureAttributeRepro.main(XalanSecureAttributeRepro.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Caused by: javax.xml.transform.TransformerException:
> org.xml.sax.SAXException: "colspan" attribute is not allowed on the th
> element!
> javax.xml.transform.TransformerException: "colspan" attribute is not allowed
> on the th element!
> at
> org.apache.xalan.processor.TransformerFactoryImpl.newTemplates(TransformerFactoryImpl.java:925)
> ... 6 more
> Caused by: org.xml.sax.SAXException: "colspan" attribute is not allowed on
> the th element!
> javax.xml.transform.TransformerException: "colspan" attribute is not allowed
> on the th element!
> at
> org.apache.xalan.processor.StylesheetHandler.error(StylesheetHandler.java:919)
> at
> org.apache.xalan.processor.StylesheetHandler.error(StylesheetHandler.java:947)
> at
> org.apache.xalan.processor.XSLTElementProcessor.setPropertie
[jira] [Commented] (XALANJ-2613) TransformerIdentityImpl doesn't properly handle file URIs with percent-encoded Unicode characters
[ https://issues.apache.org/jira/browse/XALANJ-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823775#comment-17823775 ] Lorenzo Dalla Vecchia commented on XALANJ-2613: --- I have encountered this issue, too. The target file is written, but all URL-unsafe characters are percent-encoded, creating the wrong file name. I have fixed the bug by adding URL encoding and rebuilding Xalan. Please see the attached patch [^URL-encoding-fix.diff]. > TransformerIdentityImpl doesn't properly handle file URIs with > percent-encoded Unicode characters > - > > Key: XALANJ-2613 > URL: https://issues.apache.org/jira/browse/XALANJ-2613 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: transformation >Affects Versions: 2.7.2 > Environment: I tested on the following system: > $ cat /etc/centos-release > CentOS Linux release 7.4.1708 (Core) > $ uname -a > Linux jjmdeskvm.informatica.com 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 > 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > $ env | grep -E '^LANG' > LANG=en_US.UTF-8 > $ env | grep -E '^LC' > $ >Reporter: Joshua Maurice >Assignee: Steven J. Hathaway >Priority: Major > Fix For: The Latest Development Code > > Attachments: Repro.java, URL-encoding-fix.diff, runtest.sh > > > When using Xalan, and javax.xml.transform.Transformer, with a > javax.xml.transform.stream.StreamResult constructed from a java.io.File > object that contains Unicode characters, the Transformer will create an > output file with the wrong file path. > I have attached a very small repro, which is a very small Java file and a > very small bash script used to compile and run the test, and print out a few > relevant environmental details. > > The cause of the bug is this: > When constructing a StreamResult object by passing a File object to the > constructor, the StreamResult object saves a string representation of the URI > object created from the File object. This string representation of the URI is > properly formatted, which means that the individual path elements of the path > of the URI are properly percent-encoded. The Xalan TransformerImpl class > calls getSystemId on StreamResult to get this string representation of the > URI, and it simply strips off the leading "file://" prefix, and uses the > remainder to create a FileOutputStream object. However, the remainder of the > string is the result of URI percent-encoding, and as such, it is not suitable > for directly passing to FileOutputStream. Instead, the code here must use a > URI utility to properly interpret the URI string, and to undo the > percent-encoding, to obtain a string that is suitable for creating a > FileOutputStream object. > When the file path contains only ASCII characters, percent-encoding does > nothing, which means that the code works with ASCII. However, as soon as any > other Unicode character is part of the file path, then it breaks by writing > to the wrong file path. > Because it writes to the wrong file path which may silently succeed, this may > have security concerns. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Updated] (XALANJ-2613) TransformerIdentityImpl doesn't properly handle file URIs with percent-encoded Unicode characters
[ https://issues.apache.org/jira/browse/XALANJ-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenzo Dalla Vecchia updated XALANJ-2613: -- Attachment: URL-encoding-fix.diff > TransformerIdentityImpl doesn't properly handle file URIs with > percent-encoded Unicode characters > - > > Key: XALANJ-2613 > URL: https://issues.apache.org/jira/browse/XALANJ-2613 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: transformation >Affects Versions: 2.7.2 > Environment: I tested on the following system: > $ cat /etc/centos-release > CentOS Linux release 7.4.1708 (Core) > $ uname -a > Linux jjmdeskvm.informatica.com 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 > 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux > $ env | grep -E '^LANG' > LANG=en_US.UTF-8 > $ env | grep -E '^LC' > $ >Reporter: Joshua Maurice >Assignee: Steven J. Hathaway >Priority: Major > Fix For: The Latest Development Code > > Attachments: Repro.java, URL-encoding-fix.diff, runtest.sh > > > When using Xalan, and javax.xml.transform.Transformer, with a > javax.xml.transform.stream.StreamResult constructed from a java.io.File > object that contains Unicode characters, the Transformer will create an > output file with the wrong file path. > I have attached a very small repro, which is a very small Java file and a > very small bash script used to compile and run the test, and print out a few > relevant environmental details. > > The cause of the bug is this: > When constructing a StreamResult object by passing a File object to the > constructor, the StreamResult object saves a string representation of the URI > object created from the File object. This string representation of the URI is > properly formatted, which means that the individual path elements of the path > of the URI are properly percent-encoded. The Xalan TransformerImpl class > calls getSystemId on StreamResult to get this string representation of the > URI, and it simply strips off the leading "file://" prefix, and uses the > remainder to create a FileOutputStream object. However, the remainder of the > string is the result of URI percent-encoding, and as such, it is not suitable > for directly passing to FileOutputStream. Instead, the code here must use a > URI utility to properly interpret the URI string, and to undo the > percent-encoding, to obtain a string that is suitable for creating a > FileOutputStream object. > When the file path contains only ASCII characters, percent-encoding does > nothing, which means that the code works with ASCII. However, as soon as any > other Unicode character is part of the file path, then it breaks by writing > to the wrong file path. > Because it writes to the wrong file path which may silently succeed, this may > have security concerns. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2650) The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression since 2.7.2)
[ https://issues.apache.org/jira/browse/XALANJ-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821076#comment-17821076 ] Joseph Kessselman commented on XALANJ-2650: --- Hmmm. The maven-based build for the master branch copies in LICENSE.txt and NOTICE.txt, but does not copy in META-INF/services. As a maven novice, I'm not sure what the correct fix is. > The pom file for xalan 2.7.3 and serializer 2.7.3 misses license (regression > since 2.7.2) > - > > Key: XALANJ-2650 > URL: https://issues.apache.org/jira/browse/XALANJ-2650 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Xalan >Reporter: Vladimir Sitnikov >Assignee: Gary D. Gregory >Priority: Blocker > > See [https://repo1.maven.org/maven2/xalan/xalan/2.7.3/xalan-2.7.3.pom] > The tag is missing, and 2.7.3 does not refer to a parent pom. > --- > Please: > 1) Specify the license via tag > 2) Specify the license in the jar file (Bundle-License attribute in > META-INF/MANIFEST.MF), see > [https://docs.osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-bundle-license] > 3) Include license text as META-INF/LICENSE in the jar file. See > https://issues.apache.org/jira/browse/LEGAL-642 which clarifies each jar > should include a LICENSE file. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821074#comment-17821074
]
Joseph Kessselman commented on XALANJ-2731:
---
Hmmm. The maven-based build for the master branch copies in LICENSE.txt and
NOTICE.txt, but does not copy in META-INF/services. As a maven novice, I'm not
sure what the correct fix is.
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820522#comment-17820522
]
Joe Kesselman commented on XALANJ-2731:
---
Is this still an issue with the current (Maven-based) build?
I looked at possibly adding that plugin to our pom.xml, but building with it
modified a great deal of our source, slapping additional license headers onto
files which already had that information. That's more reviewing/re-editing than
I want to deal with right now, to be perfectly honest; there are more important
things to work on.
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2732) Xalan jar is missing META-INF/services
[ https://issues.apache.org/jira/browse/XALANJ-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820378#comment-17820378 ] Joe Kesselman commented on XALANJ-2732: --- I'll take a look at it. (I would have hoped that maven's boasted defaults would have taken care of that; apparently not.) Good to know someone is actually starting to use the Maven build! > Xalan jar is missing META-INF/services > -- > > Key: XALANJ-2732 > URL: https://issues.apache.org/jira/browse/XALANJ-2732 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Affects Versions: The Latest Development Code >Reporter: Cédric Damioli >Priority: Major > > It seems that the maven build does not copy > xalan/src/main/java/META-INF/services in the jar, resulting in JAXP not > finding appropriate TransformerFactory > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2732) Xalan jar is missing META-INF/services
Cédric Damioli created XALANJ-2732: -- Summary: Xalan jar is missing META-INF/services Key: XALANJ-2732 URL: https://issues.apache.org/jira/browse/XALANJ-2732 Project: XalanJ2 Issue Type: Bug Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Affects Versions: The Latest Development Code Reporter: Cédric Damioli It seems that the maven build does not copy xalan/src/main/java/META-INF/services in the jar, resulting in JAXP not finding appropriate TransformerFactory -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Closed] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Kesselman closed XALANJ-2725. - Fix Version/s: The Latest Development Code Resolution: Fixed Merged to master; this task can now be closed, though I've recorded the technical debt to consider the other issues that it implied. > Possible buffer-boundry issue when serializing surrogate pairs > -- > > Key: XALANJ-2725 > URL: https://issues.apache.org/jira/browse/XALANJ-2725 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Serialization >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: Surrogates, escaping, unicode, utf > Fix For: The Latest Development Code > > Attachments: astral-chars-split-buffer.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > XALANJ-2419 addressed a case where "astral" Unicode characters, requiring a > surrogate pair (two UTF-16 units), were not being serialized correctly. We > have a proposed fix for that. > There is reported to still be an edge case when a surrogate pair which > crosses buffer boundaries might not be handled correctly. [~maxfortun] > offered what looks like a reasonable proposed fix > (https://github.com/maxfortun/xalan-j/blob/a9bd5591d9f8a523548aeec091e886b64c691628/src/org/apache/xml/serializer/ToStream.java#L1607), > but in my testing this was not serializing the surrogate pairs correctly, > causing regression on the tests XALANJ-2419 introduced. I don't know whether > that's because we're taking multiple paths through > But the edge case does appear to be real, and if so we will need some such > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820256#comment-17820256 ] Joe Kesselman commented on XALANJ-2725: --- Unfortunately we don't have a lot of unit tests, but the rest of the xalan-test suite still passes. I've merged my branch into master. > Possible buffer-boundry issue when serializing surrogate pairs > -- > > Key: XALANJ-2725 > URL: https://issues.apache.org/jira/browse/XALANJ-2725 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Serialization >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: Surrogates, escaping, unicode, utf > Attachments: astral-chars-split-buffer.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > XALANJ-2419 addressed a case where "astral" Unicode characters, requiring a > surrogate pair (two UTF-16 units), were not being serialized correctly. We > have a proposed fix for that. > There is reported to still be an edge case when a surrogate pair which > crosses buffer boundaries might not be handled correctly. [~maxfortun] > offered what looks like a reasonable proposed fix > (https://github.com/maxfortun/xalan-j/blob/a9bd5591d9f8a523548aeec091e886b64c691628/src/org/apache/xml/serializer/ToStream.java#L1607), > but in my testing this was not serializing the surrogate pairs correctly, > causing regression on the tests XALANJ-2419 introduced. I don't know whether > that's because we're taking multiple paths through > But the edge case does appear to be real, and if so we will need some such > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820236#comment-17820236 ] Cédric Damioli commented on XALANJ-2725: Hi [~kesh...@alum.mit.edu], I just made a few tests with your new branch, and all my previously failing tests are ok now. Does all unit tests also pass ? > Possible buffer-boundry issue when serializing surrogate pairs > -- > > Key: XALANJ-2725 > URL: https://issues.apache.org/jira/browse/XALANJ-2725 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Serialization >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: Surrogates, escaping, unicode, utf > Attachments: astral-chars-split-buffer.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > XALANJ-2419 addressed a case where "astral" Unicode characters, requiring a > surrogate pair (two UTF-16 units), were not being serialized correctly. We > have a proposed fix for that. > There is reported to still be an edge case when a surrogate pair which > crosses buffer boundaries might not be handled correctly. [~maxfortun] > offered what looks like a reasonable proposed fix > (https://github.com/maxfortun/xalan-j/blob/a9bd5591d9f8a523548aeec091e886b64c691628/src/org/apache/xml/serializer/ToStream.java#L1607), > but in my testing this was not serializing the surrogate pairs correctly, > causing regression on the tests XALANJ-2419 introduced. I don't know whether > that's because we're taking multiple paths through > But the edge case does appear to be real, and if so we will need some such > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820214#comment-17820214
]
Gary D. Gregory commented on XALANJ-2731:
-
Oops, Jira assigns new issues to me by default. I changed that.
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Assigned] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reassigned XALANJ-2731:
---
Assignee: (was: Gary D. Gregory)
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Reopened] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reopened XALANJ-2731:
-
[~singingbush]
Do NOT assign issues to people you don't known. It's not up to you to decide
who does what ;)
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Assignee: Gary D. Gregory
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17820179#comment-17820179
]
Samael Bate commented on XALANJ-2731:
-
seems this has already been reported
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Assignee: Gary D. Gregory
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Closed] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samael Bate closed XALANJ-2731.
---
Resolution: Duplicate
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Assignee: Gary D. Gregory
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Updated] (XALANJ-2731) the xalan 2.7.3 is missing license info
[
https://issues.apache.org/jira/browse/XALANJ-2731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samael Bate updated XALANJ-2731:
Description:
I use the license-maven-plugin with failOnMissing set to true but this is
causing me an issue due to the Xalan jars not having license info defined:
{noformat}
There are 2 dependencies with no license :
- xalan--serializer--2.7.3
- xalan--xalan--2.7.3{noformat}
I'm working around this be adding
{code:java}
xalan {code}
please fix the missing license info and release a bugfix version
was:
I use the license-maven-plugin with failOnMissing set to true but this is
causing me an issue due to the Xalan jars not having license info defined:
{noformat}
There are 2 dependencies with no license :
- xalan--serializer--2.7.3
- xalan--xalan--2.7.3{noformat}
please fix the missing license info and release a bugfix version
> the xalan 2.7.3 is missing license info
> ---
>
> Key: XALANJ-2731
> URL: https://issues.apache.org/jira/browse/XALANJ-2731
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Affects Versions: 2.7.3
>Reporter: Samael Bate
>Assignee: Gary D. Gregory
>Priority: Major
>
> I use the license-maven-plugin with failOnMissing set to true but this is
> causing me an issue due to the Xalan jars not having license info defined:
> {noformat}
> There are 2 dependencies with no license :
> - xalan--serializer--2.7.3
> - xalan--xalan--2.7.3{noformat}
>
> I'm working around this be adding
> {code:java}
> xalan {code}
> please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2731) the xalan 2.7.3 is missing license info
Samael Bate created XALANJ-2731:
---
Summary: the xalan 2.7.3 is missing license info
Key: XALANJ-2731
URL: https://issues.apache.org/jira/browse/XALANJ-2731
Project: XalanJ2
Issue Type: Bug
Security Level: No security risk; visible to anyone (Ordinary problems in
Xalan projects. Anybody can view the issue.)
Affects Versions: 2.7.3
Reporter: Samael Bate
Assignee: Gary D. Gregory
I use the license-maven-plugin with failOnMissing set to true but this is
causing me an issue due to the Xalan jars not having license info defined:
{noformat}
There are 2 dependencies with no license :
- xalan--serializer--2.7.3
- xalan--xalan--2.7.3{noformat}
please fix the missing license info and release a bugfix version
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2730) Review handling of isolated UTF16 surrogate characters in serializer
[
https://issues.apache.org/jira/browse/XALANJ-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819808#comment-17819808
]
Joe Kesselman commented on XALANJ-2730:
---
Copied from that previous work item:
{quote}ISSUE: Note that if a characters() call ending with a High Surrogate is
issued unintentionally, we don't currently detect the isolated High Surrogate
until the next characters() call, at which point the error indication (illegal
Numeric Character Entity for the surrogate) gets dumped in as the first
non-whitespace rather than appearing at the end of the characters() block it
belonged to. To do otherwise seems to require that all the other events check
`m_pendingUTF16HighSurrogate` and force it out before running their own logic.
Which we could do, but that's a lot of overhead for a rare error, even if the
test itself is a relatively cheap one.
{quote}
> Review handling of isolated UTF16 surrogate characters in serializer
>
>
> Key: XALANJ-2730
> URL: https://issues.apache.org/jira/browse/XALANJ-2730
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Reporter: Joe Kesselman
>Assignee: Gary D. Gregory
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819805#comment-17819805 ] Joe Kesselman commented on XALANJ-2725: --- Followup: XALANJ-2730 > Possible buffer-boundry issue when serializing surrogate pairs > -- > > Key: XALANJ-2725 > URL: https://issues.apache.org/jira/browse/XALANJ-2725 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Serialization >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: Surrogates, escaping, unicode, utf > Attachments: astral-chars-split-buffer.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > XALANJ-2419 addressed a case where "astral" Unicode characters, requiring a > surrogate pair (two UTF-16 units), were not being serialized correctly. We > have a proposed fix for that. > There is reported to still be an edge case when a surrogate pair which > crosses buffer boundaries might not be handled correctly. [~maxfortun] > offered what looks like a reasonable proposed fix > (https://github.com/maxfortun/xalan-j/blob/a9bd5591d9f8a523548aeec091e886b64c691628/src/org/apache/xml/serializer/ToStream.java#L1607), > but in my testing this was not serializing the surrogate pairs correctly, > causing regression on the tests XALANJ-2419 introduced. I don't know whether > that's because we're taking multiple paths through > But the edge case does appear to be real, and if so we will need some such > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2730) Review handling of isolated UTF16 surrogate characters in serializer
[
https://issues.apache.org/jira/browse/XALANJ-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819804#comment-17819804
]
Joe Kesselman commented on XALANJ-2730:
---
As discussed in XALANJ-2725, there are still some edge conditions possible even
after the problem of splitting output across UTF16 buffer boundaries has been
handled. I dropped some additional comments into the serializer ToStream class
to document my concerns.
If an isolated High or Low surrogate somehow gets into the data stream, we are
inconsistent in how we handle it – it may throw an exception, or it may
"silently" output the surrogate as a Numeric Character Reference – which will
not be syntactically or semantically correct per either XML or UTF16, and which
doesn't warn the user of the problem, but which does attempt to show the
problem (approximately) in context.
My _preferred_ fix would be to have malformed UTF16 input always throw
exceptions rather than trying to dance around this to output (unusable) Numeric
Character References for isolated surrogates, especially since the remaining
edge conditions are particularly ugly ones. But comments in the code seem to
suggest that we moved away from that for some reason, and I don't recall
why/how that was justified.
If we do stay with fake-NCRs for isolated surrogates, I'm seriously considering
changing them to be fake-entity-references, which will at least not be
syntactically incorrect; this could be done by replacing the current output, eg
{{{}{}}}, with something more like
{{_INVALID_UTF16_SURROGATE_55308;}} , using the MsgKey string so we at
least are in synch with the internationalization layer for clarity.
> Review handling of isolated UTF16 surrogate characters in serializer
>
>
> Key: XALANJ-2730
> URL: https://issues.apache.org/jira/browse/XALANJ-2730
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Reporter: Joe Kesselman
>Assignee: Gary D. Gregory
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Created] (XALANJ-2730) Review handling of isolated UTF16 surrogate characters in serializer
Joe Kesselman created XALANJ-2730: - Summary: Review handling of isolated UTF16 surrogate characters in serializer Key: XALANJ-2730 URL: https://issues.apache.org/jira/browse/XALANJ-2730 Project: XalanJ2 Issue Type: Bug Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Reporter: Joe Kesselman Assignee: Gary D. Gregory -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819800#comment-17819800 ] Joe Kesselman commented on XALANJ-2725: --- I'll open a new work item for the remaining technical debt > Possible buffer-boundry issue when serializing surrogate pairs > -- > > Key: XALANJ-2725 > URL: https://issues.apache.org/jira/browse/XALANJ-2725 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Serialization >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: Surrogates, escaping, unicode, utf > Attachments: astral-chars-split-buffer.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > XALANJ-2419 addressed a case where "astral" Unicode characters, requiring a > surrogate pair (two UTF-16 units), were not being serialized correctly. We > have a proposed fix for that. > There is reported to still be an edge case when a surrogate pair which > crosses buffer boundaries might not be handled correctly. [~maxfortun] > offered what looks like a reasonable proposed fix > (https://github.com/maxfortun/xalan-j/blob/a9bd5591d9f8a523548aeec091e886b64c691628/src/org/apache/xml/serializer/ToStream.java#L1607), > but in my testing this was not serializing the surrogate pairs correctly, > causing regression on the tests XALANJ-2419 introduced. I don't know whether > that's because we're taking multiple paths through > But the edge case does appear to be real, and if so we will need some such > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Comment Edited] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819441#comment-17819441 ] Joseph Kessselman edited comment on XALANJ-2725 at 2/22/24 1:43 AM: [~curc...@apache.org] : I believe you were involved in some of the serializer work, and I think some of the "write NCR rather than throw exception" changes were yours. Any opinion? (NCR, not NCE. It's a reference, not an entity. I get that wrong too at times.) was (Author: jkesselm): [~curc...@apache.org] : I believe you were involved in some of the serializer work, and I think some of the "write NCE rather than throw exception" changes were yours. Any opinion? > Possible buffer-boundry issue when serializing surrogate pairs > -- > > Key: XALANJ-2725 > URL: https://issues.apache.org/jira/browse/XALANJ-2725 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Serialization >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: Surrogates, escaping, unicode, utf > Attachments: astral-chars-split-buffer.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > XALANJ-2419 addressed a case where "astral" Unicode characters, requiring a > surrogate pair (two UTF-16 units), were not being serialized correctly. We > have a proposed fix for that. > There is reported to still be an edge case when a surrogate pair which > crosses buffer boundaries might not be handled correctly. [~maxfortun] > offered what looks like a reasonable proposed fix > (https://github.com/maxfortun/xalan-j/blob/a9bd5591d9f8a523548aeec091e886b64c691628/src/org/apache/xml/serializer/ToStream.java#L1607), > but in my testing this was not serializing the surrogate pairs correctly, > causing regression on the tests XALANJ-2419 introduced. I don't know whether > that's because we're taking multiple paths through > But the edge case does appear to be real, and if so we will need some such > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819441#comment-17819441 ] Joseph Kessselman commented on XALANJ-2725: --- [~curc...@apache.org] : I believe you were involved in some of the serializer work, and I think some of the "write NCE rather than throw exception" changes were yours. Any opinion? > Possible buffer-boundry issue when serializing surrogate pairs > -- > > Key: XALANJ-2725 > URL: https://issues.apache.org/jira/browse/XALANJ-2725 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Serialization >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: Surrogates, escaping, unicode, utf > Attachments: astral-chars-split-buffer.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > XALANJ-2419 addressed a case where "astral" Unicode characters, requiring a > surrogate pair (two UTF-16 units), were not being serialized correctly. We > have a proposed fix for that. > There is reported to still be an edge case when a surrogate pair which > crosses buffer boundaries might not be handled correctly. [~maxfortun] > offered what looks like a reasonable proposed fix > (https://github.com/maxfortun/xalan-j/blob/a9bd5591d9f8a523548aeec091e886b64c691628/src/org/apache/xml/serializer/ToStream.java#L1607), > but in my testing this was not serializing the surrogate pairs correctly, > causing regression on the tests XALANJ-2419 introduced. I don't know whether > that's because we're taking multiple paths through > But the edge case does appear to be real, and if so we will need some such > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[jira] [Commented] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17819440#comment-17819440 ] Joseph Kessselman commented on XALANJ-2725: --- Might be best to just note that as technical debt and get this much merged in, as an improvement over what we had. It *does* work better for correct data... > Possible buffer-boundry issue when serializing surrogate pairs > -- > > Key: XALANJ-2725 > URL: https://issues.apache.org/jira/browse/XALANJ-2725 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Serialization >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: Surrogates, escaping, unicode, utf > Attachments: astral-chars-split-buffer.patch > > Original Estimate: 168h > Remaining Estimate: 168h > > XALANJ-2419 addressed a case where "astral" Unicode characters, requiring a > surrogate pair (two UTF-16 units), were not being serialized correctly. We > have a proposed fix for that. > There is reported to still be an edge case when a surrogate pair which > crosses buffer boundaries might not be handled correctly. [~maxfortun] > offered what looks like a reasonable proposed fix > (https://github.com/maxfortun/xalan-j/blob/a9bd5591d9f8a523548aeec091e886b64c691628/src/org/apache/xml/serializer/ToStream.java#L1607), > but in my testing this was not serializing the surrogate pairs correctly, > causing regression on the tests XALANJ-2419 introduced. I don't know whether > that's because we're taking multiple paths through > But the edge case does appear to be real, and if so we will need some such > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
