[jira] [Commented] (XALANJ-2422) TreeWalker set systemId to dummy.xsl always (patch merge issue with XALANJ-1985)
[
https://issues.apache.org/jira/browse/XALANJ-2422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756633#comment-17756633
]
Joe Kesselman commented on XALANJ-2422:
---
*WARNING:* TreeWalker exists in both org.apache.xml.serializer and
org.apache.xml.utils, with some divergence, This was originally done to avoid
cross-dependency between the serializer and utils. We should think about
reconciling those.
It appears this user was looking at the .utils version. The logic does diverge
a bit in this function. I'm too fuzzy to reconcile them right now but wanted to
record this much.
> TreeWalker set systemId to dummy.xsl always (patch merge issue with
> XALANJ-1985)
>
>
> Key: XALANJ-2422
> URL: https://issues.apache.org/jira/browse/XALANJ-2422
> Project: XalanJ2
> Issue Type: Bug
> Components: Xalan
>Affects Versions: 2.7.1, 2.7
>Reporter: Brian McDonald
>Priority: Blocker
> Attachments: TreeWalker.patch
>
>
> If you take a look at the merge of the TreeWalker.patch
> (org/apache/xml/serializer/TreeWalker.java) between versions 338117 and
> 338053 (for XALANJ-1985), the constructor has some remnant code at the end
> which breaks it's intended functionality.
> This chunk should be removed (sorry for not attaching a patch):
> // Set the document locator
> if (m_contentHandler != null)
> m_contentHandler.setDocumentLocator(m_locator);
> try {
>// Bug see Bugzilla 26741
> m_locator.setSystemId(System.getProperty("user.dir") +
> File.separator + "dummy.xsl");
> }
> catch (SecurityException se){// user.dir not accessible from
> applet
> You can see that the constructor before this chunk already sets the document
> locator on the content handler and if the system id is null, sets the dummy
> value. Problem is that this extra chunk is setting the system id no matter
> what, which breaks all attempts to load relative files, with no workaround
> possible.
--
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-2370) java_cup - duplicate classes in classpath
[ https://issues.apache.org/jira/browse/XALANJ-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Kesselman updated XALANJ-2370: -- Component/s: XSLTC > 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] [Commented] (XALANJ-2370) java_cup - duplicate classes in classpath
[ https://issues.apache.org/jira/browse/XALANJ-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756576#comment-17756576 ] Joe Kesselman commented on XALANJ-2370: --- I think java_cup is used only by compiled-mode xalan. One traditional fix for this situation is to rework our copy of java_cup so it's in a package within org.apache.xalan, and change our references to it. This completely avoids collisions, and java_cup is a small enough package (and changes rarely enough) that this wouldn't be a disaster to maintain. Quick and dirty. Or we could try to partition classloader scopes, perhaps through OSGI. I'm aware of it but haven't used it, though I know Websphere Liberty took advantage of it to make classes load on demand rather than preloading everything at once. Complicated. Or we could try to figure out what was changed in our version of java_cup and whether there current version of the package can be used without modification. Assuming there's consensus on which version is actually the head (the one on Maven? One of the others?) and someone can remember or isolate Sun's patch (or convince us that we can run without it). > 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 >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
[GitHub] [xalan-java] mukulga merged pull request #56: fixing a codebase issue that got unknowingly introduced, with the class file XPathCollationSupport.java
mukulga merged PR #56: URL: https://github.com/apache/xalan-java/pull/56 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[GitHub] [xalan-java] mukulga opened a new pull request, #56: fixing a codebase issue that got unknowingly introduced, with the class file XPathCollationSupport.java
mukulga opened a new pull request, #56: URL: https://github.com/apache/xalan-java/pull/56 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[GitHub] [xalan-java] mukulga merged pull request #55: implementation enhancements to xpath 3.1 fn:sort function to optionally use collation uri, and committing a new relevant working test case for th
mukulga merged PR #55: URL: https://github.com/apache/xalan-java/pull/55 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
[GitHub] [xalan-java] mukulga opened a new pull request, #55: implementation enhancements to xpath 3.1 fn:sort function to optionally use collation uri, and committing a new relevant working test case
mukulga opened a new pull request, #55: URL: https://github.com/apache/xalan-java/pull/55 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
