[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.java:421) > at calmReporter.handleRequest(calmReporter.java:161) > our code: > TransformerFactory factory = TransformerFactory.newInstance(); >
[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();
> // Set the value of a in the stylesheet
> transformer.setParameter("versionParam", "2.0");
> Result res = new
Re: [PR] committing improvements to xpath 3.1 sequence type checking [xalan-java]
mukulga merged PR #175: URL: https://github.com/apache/xalan-java/pull/175 -- 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
[PR] committing improvements to xpath 3.1 sequence type checking [xalan-java]
mukulga opened a new pull request, #175: URL: https://github.com/apache/xalan-java/pull/175 (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
