[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
[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=17819439#comment-17819439 ] Joseph Kessselman commented on XALANJ-2725: --- Added code for isolated High Surrogate. People do mishandle UTF16 strings, alas, so safety nets are needed. BUT, 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. Feels like there ought to be a cleaner answer than that, but I'm not convinced there is one – other than just saying "Nope, bad data, throw exception", which we seem to have moved away from in past decisions > 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=17819375#comment-17819375 ] Joseph Kessselman commented on XALANJ-2725: --- (Took me a little while to remember how the dirty/clean optimization works in characters() and to integrate that into this patch.) ISSUE: As written I think this will correctly handle isolated Low Surrogate. However, I think it will discard isolated High Surrogate. Handling that case seems to require moving this logic to the top of the loop, so we we can recognize and handle that case. > 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=17819374#comment-17819374 ] Joseph Kessselman commented on XALANJ-2725: --- Checked in a fix for ToStream.characters(), on my branch [https://github.com/apache/xalan-java/tree/XALANJ-2725]. It passes the test added in [https://github.com/apache/xalan-test/tree/XALANJ-2725|https://github.com/apache/xalan-test/tree/XALANJ-2725.]. Not convinced it's the cleanest possible, and I want to sanity-check the other surrogate handling to see if they need the same thing applied But it does solve the reported bug. > 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=17818231#comment-17818231 ] Joseph Kessselman commented on XALANJ-2725: --- (Yeah, I know, I'm overcomplicating. I'd just rather solve the whole problem, given a choice.) > 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=17818226#comment-17818226 ] Joseph Kessselman commented on XALANJ-2725: --- Resuming looking at this. The main issue I see with using a state variable is that, done right, it seems to force every pass through the rendering loop to check for "high surrogate was encountered but not followed by a low surrogate." I can move the surrogate handling to the top of the loop, but I'm slightly concerned about performance, even though "Is this a high/low surrogate" should be a fast and simple mask test that could be inlined during JIT compilation. And we really should consider what happens if the high surrogate is at end of buffer but the next call is an event other than characters(); that may mean elements and such also need to check for a leftover high and handle it. Ditto switching into or out of CDATA section rendering. Pondering whether there is a good way to simplify/clarify this. And I'm really not delighted with the "silent failure" of outputting isolated surrogates as inappropriate numeric character references, especially since we're inconsistent about that... see past discussion about whether that should be normalized and configurable. > 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] [Resolved] (XALANJ-2729) Implementing support for xpath 3.1 function fn:base-uri, for XalanJ's interpretive processor
[ https://issues.apache.org/jira/browse/XALANJ-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2729. -- Resolution: Fixed I'm marking this jira issue as resolved, since implementation for this jira issue, has been committed to the XalanJ dev repos's branch xalan-j_xslt3.0. > Implementing support for xpath 3.1 function fn:base-uri, for XalanJ's > interpretive processor > > > Key: XALANJ-2729 > URL: https://issues.apache.org/jira/browse/XALANJ-2729 > 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-interpretive, 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:base-uri. > I've written little bit of code for this, that has been committed to XalanJ > dev repos's branch xalan-j_xslt3.0. -- 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-2729) Implementing support for xpath 3.1 function fn:base-uri, for XalanJ's interpretive processor
Mukul Gandhi created XALANJ-2729: Summary: Implementing support for xpath 3.1 function fn:base-uri, for XalanJ's interpretive processor Key: XALANJ-2729 URL: https://issues.apache.org/jira/browse/XALANJ-2729 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-interpretive, XPath-function Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue, to track implementation of xpath 3.1 function fn:base-uri. I've written little bit of code for this, that has been committed to XalanJ dev repos's branch xalan-j_xslt3.0. -- 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-2727) There are numerous javadoc errors in the master branch
[ https://issues.apache.org/jira/browse/XALANJ-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17815993#comment-17815993 ] Samael Bate commented on XALANJ-2727: - please can someone approve the workflow on [https://github.com/apache/xalan-java/pull/176] and take a look at potentially merging it. > There are numerous javadoc errors in the master branch > -- > > Key: XALANJ-2727 > URL: https://issues.apache.org/jira/browse/XALANJ-2727 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Samael Bate >Priority: Major > > after cloning and running the maven build I found a lot of javadoc errors. > I'll make a PR with the some 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] [Resolved] (XALANJ-2728) Implementing support for few new system properties for the function fn:system-property, for XalanJ's interpretive processor
[ https://issues.apache.org/jira/browse/XALANJ-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2728. -- Resolution: Fixed I'm marking this jira issue as resolved, since implementation for this jira issue, has been committed to the XalanJ dev repos's branch xalan-j_xslt3.0. Following new xslt 3.0 related system properties have been implemented, xsl:is-schema-aware (with value 'partial') xsl:supports-serialization (with value 'partial') xsl:supports-streaming (with value 'no') xsl:supports-higher-order-functions(with value 'yes') xsl:xpath-version (with value '3.1') xsl:xsd-version (with value '1.0') The value of system property xsl:version now returns value '3.0' instead of '1.0' earlier. > Implementing support for few new system properties for the function > fn:system-property, for XalanJ's interpretive processor > --- > > Key: XALANJ-2728 > URL: https://issues.apache.org/jira/browse/XALANJ-2728 > 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-interpretive >Reporter: Mukul Gandhi >Assignee: Mukul Gandhi >Priority: Major > > I'm creating this jira issue, to track implementation enhancements of xslt > 3.0 function fn:system-property. > I've written little bit of code for this, that has been committed to XalanJ > dev repos's branch xalan-j_xslt3.0. -- 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-2728) Implementing support for few new system properties for the function fn:system-property, for XalanJ's interpretive processor
Mukul Gandhi created XALANJ-2728: Summary: Implementing support for few new system properties for the function fn:system-property, for XalanJ's interpretive processor Key: XALANJ-2728 URL: https://issues.apache.org/jira/browse/XALANJ-2728 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-interpretive Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue, to track implementation enhancements of xslt 3.0 function fn:system-property. I've written little bit of code for this, that has been committed to XalanJ dev repos's branch xalan-j_xslt3.0. -- 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-2651) Migrate build from Ant to Maven
[ https://issues.apache.org/jira/browse/XALANJ-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814958#comment-17814958 ] Joe Kesselman commented on XALANJ-2651: --- Folding xalan-test into Xalan should be a separate Jira task, and needs discussion; see past comments in the developers mailing list. xalan-test was intended to be usable to test Xalan-J, xalan-c, and other processors other processors. Well some of it's tests are specific to xalan, most of them are conformance tests against the standard rather than our specific code. Although we have moved the C++ code to the Apache attic, the generality of these tests still remains, and is still an argument for keeping them separate. Also, the current test drivers are fairly tightly integrated with Apache at. Migrating the tests to work with the new maven-based build for xalan-j could be complicated. Of course, as a short-term measure, we can have the maven build invoke the ant build, but that's a bit ugly. Also, it can be argued that what the Java source package really needs is an entirely new suite of unit tests, rather than the functional and integration tests provided by the current test package. So that would be a huge task, and for immediate purposes might be a case of boiling the ocean to make a cup of tea. So there are decisions to be made here, And discussing that kind of direction is generally a function of the mailing list rather than jira tasks. The task is more about the details of how, where the mailing list addresses what and why. It's a worthwhile question. But _this_ jira task is not the right place to dive into it. Open a new one, or bring it up in the mail list. Or both. We still need to address the question of whether a copy of the test suite will ship with the source bundles. Historically, we have included it, and we probably should continue to do so. However, that has not yet been integrated into the maven build. I don't have the cycles for it right now, but I would like to see that resolved one way or another before closing out this work item. > Migrate build from Ant to Maven > --- > > Key: XALANJ-2651 > URL: https://issues.apache.org/jira/browse/XALANJ-2651 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Build >Reporter: Gary D. Gregory >Assignee: Joe Kesselman >Priority: Major > > Migrate the build from Ant to Maven. -- 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-2651) Migrate build from Ant to Maven
[
https://issues.apache.org/jira/browse/XALANJ-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814947#comment-17814947
]
Samael Bate commented on XALANJ-2651:
-
It's worth considering bringing the tests in from the
[https://github.com/apache/xalan-test] repo as a maven module within
xalan-java. Keeping all the xalan stuff together in a single maven project
would work well and it's possible to exclude particular modules from being
published by specifying the following in the pom of the module in question:
{code:java}
org.apache.maven.plugins
maven-deploy-plugin
true
{code}
I'm willing to have a go if this is acceptable.
> Migrate build from Ant to Maven
> ---
>
> Key: XALANJ-2651
> URL: https://issues.apache.org/jira/browse/XALANJ-2651
> Project: XalanJ2
> Issue Type: Improvement
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: Build
>Reporter: Gary D. Gregory
>Assignee: Joe Kesselman
>Priority: Major
>
> Migrate the build from Ant to Maven.
--
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-2727) There are numerous javadoc errors in the master branch
[ https://issues.apache.org/jira/browse/XALANJ-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814942#comment-17814942 ] Samael Bate commented on XALANJ-2727: - I didn't assign this. I think someone with Jira permissions will need to change the project config > There are numerous javadoc errors in the master branch > -- > > Key: XALANJ-2727 > URL: https://issues.apache.org/jira/browse/XALANJ-2727 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Samael Bate >Priority: Major > > after cloning and running the maven build I found a lot of javadoc errors. > I'll make a PR with the some 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] [Commented] (XALANJ-2727) There are numerous javadoc errors in the master branch
[ https://issues.apache.org/jira/browse/XALANJ-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814912#comment-17814912 ] Gary D. Gregory commented on XALANJ-2727: - [~singingbush] Please don't assign issues. > There are numerous javadoc errors in the master branch > -- > > Key: XALANJ-2727 > URL: https://issues.apache.org/jira/browse/XALANJ-2727 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Samael Bate >Assignee: Gary D. Gregory >Priority: Major > > after cloning and running the maven build I found a lot of javadoc errors. > I'll make a PR with the some 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] [Assigned] (XALANJ-2727) There are numerous javadoc errors in the master branch
[ https://issues.apache.org/jira/browse/XALANJ-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory reassigned XALANJ-2727: --- Assignee: (was: Gary D. Gregory) > There are numerous javadoc errors in the master branch > -- > > Key: XALANJ-2727 > URL: https://issues.apache.org/jira/browse/XALANJ-2727 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Samael Bate >Priority: Major > > after cloning and running the maven build I found a lot of javadoc errors. > I'll make a PR with the some 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] [Commented] (XALANJ-2727) There are numerous javadoc errors in the master branch
[ https://issues.apache.org/jira/browse/XALANJ-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814893#comment-17814893 ] Samael Bate commented on XALANJ-2727: - PR here: [https://github.com/apache/xalan-java/pull/176] > There are numerous javadoc errors in the master branch > -- > > Key: XALANJ-2727 > URL: https://issues.apache.org/jira/browse/XALANJ-2727 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) >Reporter: Samael Bate >Assignee: Gary D. Gregory >Priority: Major > > after cloning and running the maven build I found a lot of javadoc errors. > I'll make a PR with the some 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-2727) There are numerous javadoc errors in the master branch
Samael Bate created XALANJ-2727: --- Summary: There are numerous javadoc errors in the master branch Key: XALANJ-2727 URL: https://issues.apache.org/jira/browse/XALANJ-2727 Project: XalanJ2 Issue Type: Bug Security Level: No security risk; visible to anyone (Ordinary problems in Xalan projects. Anybody can view the issue.) Reporter: Samael Bate Assignee: Gary D. Gregory after cloning and running the maven build I found a lot of javadoc errors. I'll make a PR with the some 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] [Resolved] (XALANJ-2608) Java Heap Space Error from DTMDefaultBase
[
https://issues.apache.org/jira/browse/XALANJ-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Kesselman resolved XALANJ-2608.
---
Resolution: Incomplete
Insufficient information to reproduce. Breaking up the document and later
reassembling, or filtering irrelevant parts out of the input, or using
incremental with the discard extension, or simply increasing heap size, are the
usual approaches. Some day sone if that may be able to be di e automatically
--IBM has a few patents related to that – or the XSLT 3.0 streaming model, may
help with large documents, but Xalan does not currently implement those
concepts.
One thought: If you are using DOM input, try switching to SAX. Our DTM document
model was explicitly designed to pack large documents into less memory than an
object based DOM can.
> Java Heap Space Error from DTMDefaultBase
> -
>
> Key: XALANJ-2608
> URL: https://issues.apache.org/jira/browse/XALANJ-2608
> Project: XalanJ2
> Issue Type: Bug
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: DTM
>Affects Versions: 2.7.1, 2.7.2
> Environment: Windows 7 Entreprise Service Pack 1
> Java 8 update 122 - MaxHeapSize = 4GB
>Reporter: khaled khalifa
>Assignee: Steven J. Hathaway
>Priority: Major
> Attachments: IBXsltUtils.java, PIM_export.xslt, XSLTSample.java,
> java_leak_problem.PNG
>
>
> When trying to gnerate a large xml file (1.5 GB) via un batch (spring-batch)
> we get a *java.lang.OutOfMemoryError: Java heap space*
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.xml.dtm.ref.DTMDefaultBase.ensureSizeOfIndex(DTMDefaultBase.java:302)
> at
> org.apache.xml.dtm.ref.DTMDefaultBase.indexNode(DTMDefaultBase.java:328)
> at
> org.apache.xml.dtm.ref.sax2dtm.SAX2DTM.startElement(SAX2DTM.java:1887)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown
> Source)
> at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown
> Source)
> at
> com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown
> Source)
> at
> org.apache.xml.dtm.ref.DTMManagerDefault.getDTM(DTMManagerDefault.java:439)
> at
> org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:701)
> at
> org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1275)
> at
> org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1253)
> {code}
> In the attachment you may find a screenshot of the java analyser for the leak
--
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-2603) Xalan 2.7.1
[ https://issues.apache.org/jira/browse/XALANJ-2603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Kesselman resolved XALANJ-2603. --- Resolution: Incomplete Not enough information to reproduce. > Xalan 2.7.1 > --- > > Key: XALANJ-2603 > URL: https://issues.apache.org/jira/browse/XALANJ-2603 > 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 >Affects Versions: 2.7.1 >Reporter: HITESH MEHRA >Assignee: Steven J. Hathaway >Priority: Major > > Hi Team, > We were using the Xalan 2.7.1 in our Java application which was deployed in > Solaris with JDK 1.7, 32 bit. The XSL were also compiled in JDK 1.7, 32 bit. > We are parsing our XML and using the node() function in some conditions like > below: > [descendant::node() != ''] > But we recently moved our application to CentOS with JDK 1.8 64 bit. The XSL > were compiled in JDK 1.8, 64 bit. After this migration/upgrade in production > , we are now having issues with the above condition (yes, we missed to test > this corner scenario in QA environment) . The above condition is always > returning false. > And due to this, our XML is not getting properly parsed. > Do we know if this feature is OS/JDK dependent. > Any pointers will be extremely helpful. -- 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-2635) Remove JLex.jar from the source repository
[
https://issues.apache.org/jira/browse/XALANJ-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Kesselman resolved XALANJ-2635.
---
Resolution: Fixed
> Remove JLex.jar from the source repository
> --
>
> Key: XALANJ-2635
> URL: https://issues.apache.org/jira/browse/XALANJ-2635
> Project: XalanJ2
> Issue Type: Task
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
> Components: XSLTC
>Reporter: Vladimir Sitnikov
>Assignee: Gary D. Gregory
>Priority: Major
>
> https://github.com/apache/xalan-java/tree/master/tools contains JLex.jar
> which is a binary file, and its provenance is unknown.
> The ASF rules forbid compiled including compiled code to the source
> repository (see
> https://lists.apache.org/thread/otx07h6vbjrsqd9r9sqpcpjscvjwtmfc), and in
> this case, there's no real need to have JLex.jar in the source repository.
> At the same time, the generated
> {{xalan-java/src/org/apache/xalan/xsltc/compiler/XPathLexer.java}} should be
> removed from the source control.
> I suggest that JLex.jar should be removed and it should be replaced with
> something else.
> For instance, the source code of JLex could be added as a separate subfolder,
> and xalan could compile JLex from sources.
> It looks like the official distribution is not maintained:
> https://www.cs.princeton.edu/~appel/modern/java/JLex/
--
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-2710) Use resource files for version numbers
[
https://issues.apache.org/jira/browse/XALANJ-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Kesselman resolved XALANJ-2710.
---
Resolution: Fixed
> Use resource files for version numbers
> --
>
> Key: XALANJ-2710
> URL: https://issues.apache.org/jira/browse/XALANJ-2710
> Project: XalanJ2
> Issue Type: New Feature
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Reporter: Alexander Kriegisch
>Assignee: Gary D. Gregory
>Priority: Major
> Attachments: screenshot-1.png
>
>
> The current Ant build uses {{\*.src}} files, replaces placeholders with
> version numbers there, then renames them to {{\*.java}} and copies them to
> their respective destination directories.
> In the current Maven build in branch {{{}xalan-java-mvn-refactored{}}}, this
> should be replaced by simple, standardised Maven resource filtering. The
> values would be written into a properties file, which then in turn will be
> read as normal classpath resources from Java classes that need version
> information.
> Even easier than that would be to simply use the standard
> {{META-INF/maven/[groupId]/[artifactId]/pom.properties}} file generated into
> JARs by Maven anyway. They look like this:
> {code:java}
> artifactId=xalan
> groupId=xalan
> version=2.7.3
> {code}
> The only drawback here is that each corresponding Java file per module would
> need to know its own group and artifact ID in order to locate the resource
> file. But those usually do not change often, and it would be the cheapest
> solution to just hard-code them into the corresponding {{*Version.java}}
> file. Creating extra resource files with a fixed paths would be more work and
> the exact location would also have to be hard-coded into the Java files.
> Outside the JAR file context, e.g. when running tests from an IDE, the file
> would be located in {{{}target/maven-archiver/pom.properties{}}}, i.e. the
> Java classes reading the version numbers would need to try that path as a
> fallback.
--
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-2707) Javadoc taglet depends upon deprecated classes?
[ https://issues.apache.org/jira/browse/XALANJ-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Kesselman resolved XALANJ-2707. --- Fix Version/s: The Latest Development Code Assignee: Joe Kesselman Resolution: Fixed Resolved in Maven build; source for both pre and post Java8 present and Maven builds whichever is appropriate. Some mostly-harmless errors may appear in IDEs Longer term, deprecate Java 8 as build environment. > Javadoc taglet depends upon deprecated classes? > --- > > Key: XALANJ-2707 > URL: https://issues.apache.org/jira/browse/XALANJ-2707 > Project: XalanJ2 > Issue Type: Improvement > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: Documentation > Environment: JDK more recent than 1.8 >Reporter: Joe Kesselman >Assignee: Joe Kesselman >Priority: Major > Labels: build, documentation, java-migration > Fix For: The Latest Development Code > > Original Estimate: 72h > Remaining Estimate: 72h > > *Possible blocker for XALANJ-2651* > In decompiling the xalan2j-taglet code as part of the maven build effort, we > discovered that it appears to have dependencies upon com.sun.* code which > Went Away after Java 8. We'd been getting away with it because we'd been > running from a prebuilt jarfile, but as it stands this may interfere with > doing a full build on more recent Java releases. > Current thoughts: > 0) Build only on Java 8. Ugh. > 1) Build javadocs only on Java 8, accept that they fail elsewhere. Less ugh, > but still ugh. > 2) Check in a canned copy of this module's jarfile, so we can run without > building it. That's essentially what we were doing in pre-Mavenization days. > Perhaps not rebuild it automagically as part of Xalan build. > 3) Post this taglet module to Maven, reference it from there, so Xalan build > doesn't have to deal with the issue. > 4) Make the taglet code introspect and use the newer or older interfaces to > those functions as available. > Right now I'm treating this as technical debt, but we should consider whether > switching to Maven requires resolving it. -- 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-2537) The SAX exception occurs in Tansformer.transform() for a very large xml string as input.
[ https://issues.apache.org/jira/browse/XALANJ-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737909#comment-17737909 ] Joe Kesselman edited comment on XALANJ-2537 at 2/5/24 7:14 PM: --- Handling huge documents is a problem for any XSLT processor. XSLT 3.0 introduced the concept of a streaming subset of the language specifically for that purpose, and IBM has some patents (but not product as far as I know) on the topic of how to optimize/rewrite a stylesheet into a streamable form. That might or might not address this use case. If not, huge amounts of memory or partitioning the problem may be unavoidable. I believe Saxon does have some streaming capability, though I don't know how much. IBM's DB2 database does support XQuery, which is functionally equivalent to XSLT; I don't know whether it supports XSLT syntax. Since DB2 scales up to huge data structures, it might be able to run queries that Xalan will never be able to handle directly. At one point we added some extension functions to Xalan to let users explicitly indicate that a subtree would never again be referenced and could be discarded. I don't know offhand whether that mechanism still exists. Depending on what you are trying to do, it may also be possible to pre filter the input document, or break it into smaller documents which can be processed separately and then recombined. was (Author: JIRAUSER285361): Handling huge documents is a problem for any XSLT processor. XSLT 3.0 introduced the concept of a streaming subset of the language specifically for that purpose, and IBM has some patents (but not product as far as I know) on the topic of how to optimize/rewrite a stylesheet into a streamable form. That might or might not address this use case. If not, huge amounts of memory or partitioning the problem may be unavoidable. I believe Saxon does have some streaming capability, though I don't know how much. IBM's DB2 database does support XQuery, which is functionally equivalent to XSLT; I don't know whether it supports XSLT syntax. Since DB2 scales up to huge data structures, it might be able to run queries that Xalan will never be able to handle directly. At one point we added some extension functions to Xalan to let users explicitly indicate that a subtree would never again be referenced and could be discarded. I don't know offhand whether that mechanism still exists. > The SAX exception occurs in Tansformer.transform() for a very large xml > string as input. > - > > Key: XALANJ-2537 > URL: https://issues.apache.org/jira/browse/XALANJ-2537 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: SAX >Affects Versions: 2.7 > Environment: Linux >Reporter: Deepthi BakkaVemana >Priority: Blocker > Labels: sax_exception_for_Largexml > > We are using xalan 2.7.0 and fop 0.95 for generating PDF reports.While > generating pdf report for a large xml string of 2,96,126 characters(~ nearly > 3 lakh characters) ,the PDF generation fails and it fails at > transformer.transform() method in TransformerImpl.java.Since in our > product,we need large reports with very large strings(events),we need this > fix ASAP. > I et the below exception: javax.xml.transform.TransformerException: > org.xml.sax.SAXException: Mismatch: page-sequence > (http://www.w3.org/1999/XSL/Format) vs. root > (http://www.w3.org/1999/XSL/Format) > at > org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:725) > at > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2243) > at > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2069) > at > org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1171) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:634) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1088) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1066) > at > com.ca.calm.reporter.pdf.PDFGenerator.buildPdf(PDFGenerator.java:1312) > at > com.ca.calm.reporter.pdf.PDFGenerator.generatePdfForQueryView(PDFGenerator.java:1240) > at > com.ca.calm.reporter.pdf.PDFGenerator.exportPanel(PDFGenerator.java:186) > at calmReporter.exportPanel(calmReporter.ja
[jira] [Comment Edited] (XALANJ-2537) The SAX exception occurs in Tansformer.transform() for a very large xml string as input.
[ https://issues.apache.org/jira/browse/XALANJ-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737909#comment-17737909 ] Joe Kesselman edited comment on XALANJ-2537 at 2/5/24 7:13 PM: --- Handling huge documents is a problem for any XSLT processor. XSLT 3.0 introduced the concept of a streaming subset of the language specifically for that purpose, and IBM has some patents (but not product as far as I know) on the topic of how to optimize/rewrite a stylesheet into a streamable form. That might or might not address this use case. If not, huge amounts of memory or partitioning the problem may be unavoidable. I believe Saxon does have some streaming capability, though I don't know how much. IBM's DB2 database does support XQuery, which is functionally equivalent to XSLT; I don't know whether it supports XSLT syntax. Since DB2 scales up to huge data structures, it might be able to run queries that Xalan will never be able to handle directly. At one point we added some extension functions to Xalan to let users explicitly indicate that a subtree would never again be referenced and could be discarded. I don't know offhand whether that mechanism still exists. was (Author: JIRAUSER285361): Handling huge documents is a problem for any XSLT processor. XSLT 3.0 introduced the concept of a streaming subset of the language specifically for that purpose, and IBM has some patents (but not product as far as I know) on the topic of how to optimize/rewrite a stylesheet into a streamable form. That might or might not address this use case. If not, huge amounts of memory or partitioning the problem may be unavoidable. I believe Saxon does have some streaming capability, though I don't know how much. IBM's DB2 database does support XQuery, which is functionally equivalent to XSLT; I don't know whether it supports XSLT syntax. Since DB2 scales up to huge data structures, it might be able to run queries that Xalan will never be able to handle directly. > The SAX exception occurs in Tansformer.transform() for a very large xml > string as input. > - > > Key: XALANJ-2537 > URL: https://issues.apache.org/jira/browse/XALANJ-2537 > Project: XalanJ2 > Issue Type: Bug > Security Level: No security risk; visible to anyone(Ordinary problems in > Xalan projects. Anybody can view the issue.) > Components: SAX >Affects Versions: 2.7 > Environment: Linux >Reporter: Deepthi BakkaVemana >Priority: Blocker > Labels: sax_exception_for_Largexml > > We are using xalan 2.7.0 and fop 0.95 for generating PDF reports.While > generating pdf report for a large xml string of 2,96,126 characters(~ nearly > 3 lakh characters) ,the PDF generation fails and it fails at > transformer.transform() method in TransformerImpl.java.Since in our > product,we need large reports with very large strings(events),we need this > fix ASAP. > I et the below exception: javax.xml.transform.TransformerException: > org.xml.sax.SAXException: Mismatch: page-sequence > (http://www.w3.org/1999/XSL/Format) vs. root > (http://www.w3.org/1999/XSL/Format) > at > org.apache.xalan.templates.ElemLiteralResult.execute(ElemLiteralResult.java:725) > at > org.apache.xalan.transformer.TransformerImpl.executeChildTemplates(TransformerImpl.java:2243) > at > org.apache.xalan.transformer.TransformerImpl.applyTemplateToNode(TransformerImpl.java:2069) > at > org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1171) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:634) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1088) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImpl.java:1066) > at > com.ca.calm.reporter.pdf.PDFGenerator.buildPdf(PDFGenerator.java:1312) > at > com.ca.calm.reporter.pdf.PDFGenerator.generatePdfForQueryView(PDFGenerator.java:1240) > at > com.ca.calm.reporter.pdf.PDFGenerator.exportPanel(PDFGenerator.java:186) > at calmReporter.exportPanel(calmReporter.java:421) > at calmReporter.handleRequest(calmReporter.java:161) > our code: > TransformerFactory factory = TransformerFactory.newInstance(); > Templates templates = factory.newTemplates(new > SAXSource(new InputSource( > new StringReader(xslContent; > Transformer transformer = templates.newTransformer(); >
[jira] [Resolved] (XALANJ-2726) Implementation of xpath 3.1 function fn:default-collation, for XalanJ's interpretive processor
[ https://issues.apache.org/jira/browse/XALANJ-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Gandhi resolved XALANJ-2726. -- Resolution: Fixed I'm marking this jira issue as resolved, since implementation for this jira issue, has been committed to the XalanJ dev repos's branch xalan-j_xslt3.0. > Implementation of xpath 3.1 function fn:default-collation, for XalanJ's > interpretive processor > -- > > Key: XALANJ-2726 > URL: https://issues.apache.org/jira/browse/XALANJ-2726 > 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: Xalan-interpretive, 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:default-collation. > I've written little bit of code for this, that has been committed to XalanJ > dev repos's branch xalan-j_xslt3.0. Few related working test cases for these > implementation aspects, have been committed as well to the same XalanJ dev > repos's branch. -- 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-2726) Implementation of xpath 3.1 function fn:default-collation, for XalanJ's interpretive processor
Mukul Gandhi created XALANJ-2726: Summary: Implementation of xpath 3.1 function fn:default-collation, for XalanJ's interpretive processor Key: XALANJ-2726 URL: https://issues.apache.org/jira/browse/XALANJ-2726 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: Xalan-interpretive, XPath-function Reporter: Mukul Gandhi Assignee: Mukul Gandhi I'm creating this jira issue, to track implementation of xpath 3.1 function fn:default-collation. I've written little bit of code for this, that has been committed to XalanJ dev repos's branch xalan-j_xslt3.0. Few related working test cases for these implementation aspects, have been committed as well to the same XalanJ dev repos's branch. -- 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=17812766#comment-17812766 ] Max commented on XALANJ-2725: - [~kesh...@alum.mit.edu] , thank you for the heads up, and for actually working on this at all. This project has been in deep neglect until you gave it some love. Good luck and rooting for your return :) > 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=17812757#comment-17812757 ] Joe Kesselman commented on XALANJ-2725: --- FYI, I have other demands on my time for the next two weeks; progress may be slow as a result. > 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=17812145#comment-17812145 ] Joseph Kessselman commented on XALANJ-2725: --- (Sigh. Still dealing with half the time being logged into Git as keshlam@kubyc.solutions account and the other half as jkess...@apache.org. Apologies if that confuses folks; I'll try to get it straightened out.) > 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=17811990#comment-17811990 ] Joseph Kessselman commented on XALANJ-2725: --- Started XALANJ-2725 branches for this, merged your test into that. Thanks! > 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] (XALANJ-2725) Possible buffer-boundry issue when serializing surrogate pairs
[ https://issues.apache.org/jira/browse/XALANJ-2725 ] Joseph Kessselman deleted comment on XALANJ-2725: --- was (Author: jkesselm): Thanks for the test contribution. I'm going to defer merging it a bit, so hopefully we have the fix at the same time. > 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=17811984#comment-17811984 ] Joseph Kessselman commented on XALANJ-2725: --- Thanks for the test contribution. I'm going to defer merging it a bit, so hopefully we have the fix at the same time. > 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
