[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560317#action_12560317 ] Marcel Reutegger commented on JCR-1312: --- Jukka wrote: I'd resolve this as Won't Fix. +1 Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559856#action_12559856 ] Jukka Zitting commented on JCR-1312: Jackrabbit is not an XML parser project. Definitely agreed on that one. And yet you're proposing to add 350+ LOC with no other purpose than XML parsing. The code is nontrivial and I'm certainly not convinced that it doesn't have bugs or doesn't overlook some DOM semantics that we may or may not rely on. IMHO given advantages (memory footprint (1% of Xerces) and performance (40-60% of Xerces)) this is probably a small price to pay :-) I don't agree. JCR-1310 is a better way to drop the Xerces jar and the performance improvement is IMHO only relevant if it translates to real-world use cases. I don't see that happening here, especially in light of what Julian and Ian said, but feel free to prove me otherwise. I'd resolve this as Won't Fix. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559858#action_12559858 ] Felix Meschberger commented on JCR-1312: Yes, but most of these 350+ lines of code are copied and used elsewhere ... So chances are, they are very well tested. Given real-world performance figure requirements: I tested these while accessing the repository using Gnome VFS and browsing around in the repository and creating/deleting files ! So this is certainly kind of real-world. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Am Mittwoch, den 16.01.2008, 17:01 +0100 schrieb Thomas Mueller: Hi, My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? Definitely +1, esp. since using JAXP you can never be sure, which parser you actually get and end up trying to workaround bugs of all venues ... For these reasons, I like small and simple ones doing what I need and not providing functionality I probably never will need (e.g. XNI) in the near feature Regards Felix Regards, Thomas
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559859#action_12559859 ] Jukka Zitting commented on JCR-1312: copied and used elsewhere is a warning sign. We should be getting that functionality from a library, not duplicating it in our codebase. Did you see the 40-60% performance improvement when using VFS? If that's right (figures, test setup?), then yes, I'd be ready to even duplicate code! Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Felix Meschberger wrote: Am Mittwoch, den 16.01.2008, 17:01 +0100 schrieb Thomas Mueller: Hi, My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? Definitely +1, esp. since using JAXP you can never be sure, which parser you actually get and end up trying to workaround bugs of all venues ... We suffered from this problem in Cocoon for years - although we felt that using JAXP was the way to go. So we created a lot of workarounds for various bugs in the different implementations - which obviously is rather ugly. Then we decided to require a specific version of the parser which is as bug free as possible. So users had to put it up into the hell of lib/endorsed - and of course this created a bunch of other problems (users forgot about it or were not allowed etc.). So the final solution is to ensure to use the right version without relying on others (being it users or the jdk). The only way of achieving this however is to have an own classloader...so, although we are speaking of a webapp, the webapp creates its own classloader which loads acts classes from WEB-INF/classes and WEB-INF/lib *before* the parent classloader. Then you can put the JAXP impl into WEB-INF/lib and are done. Ok, heavy solution for such a problem. But it even gets better :) (stranger?): We also developed a maven plugin that created this classloader during development: every servlet, filter, listener etc. declared in web.xml gets wrapped by an own implementation using the custom classloader. So the whole thing is transparent (and therefore even more scary). Just to give another option/opinion. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, getting that functionality from a library The problem I see is version conflicts. What if the application uses a different version of the same library. copied and used elsewhere Do these +350 lines mean completely avoiding version conflicts and removing one dependency? That would sounds OK to me. Personally, I really don't like copied source code inside the same project. using JAXP you can never be sure which parser you actually get Trying to support all XML parser implementations and versions sounds a bit like trying to support all SQL databases to me. What do other people think about using JAXP? Those links are a bit old: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00787.html https://jaxp.dev.java.net/1.4/JAXP-Compatibility.html Regards, Thomas
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559878#action_12559878 ] Felix Meschberger commented on JCR-1312: Test setup is: * I count the number of milliseconds used to parse the request or serialize the response inside the respective class (there are fortunately only two locations, one parsing and one serializing). To get somewhat meaningfull numbers, I force repeated parsing and serialization on a single request. * Server was a microsling setup, that is standard Simple WebDAV servlet configuration * Client and server was a Fedorar 7 machine running Java 5 I do not have the absolute numbers anymore... And yes, the improvement is just parsing and serializing, the other parameters were unchanged, that is completely ignoring and kernel networking latency etc. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, On Jan 16, 2008 6:01 PM, Thomas Mueller [EMAIL PROTECTED] wrote: My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? In Jackrabbit we only use a fairly standard subset of XML functionality, mainly just parsing and serialization of relatively simple XML documents. I think the only real XML parser incompatibility issue we've faced is the xmlns serialization issue, and we have good workarounds for that. So I don't see us having many problems with using standard JAXP, and given the classloading horrors described by Carsten I would very much prefer sticking with standard JAXP. BR, Jukka Zitting
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559884#action_12559884 ] Jukka Zitting commented on JCR-1312: completely ignoring and kernel networking latency etc. That's my point. I would assume that the time taken by XML parsing is insignificant when compared to both HTTP processing above and JCR processing below. Even assuming zero network and disk latencies, I don't believe that XML parsing is taking more than a fraction of total request processing time. Even a 50% performance boost to XML parsing is not likely to give any visible changes to end user performance. Besides, CPU performance is seldom the bottleneck in applications today. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, Am Donnerstag, den 17.01.2008, 11:53 +0200 schrieb Jukka Zitting: Hi, On Jan 16, 2008 6:01 PM, Thomas Mueller [EMAIL PROTECTED] wrote: My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? In Jackrabbit we only use a fairly standard subset of XML functionality, mainly just parsing and serialization of relatively simple XML documents. I think the only real XML parser incompatibility issue we've faced is the xmlns serialization issue, and we have good workarounds for that. So I don't see us having many problems with using standard JAXP, and given the classloading horrors described by Carsten I would very much prefer sticking with standard JAXP. I am not totally fluent with the state nowadays: But hasn't there been a time, that Java 1.4 included a buggy Xerces version, which could only be replaced by hacking the boot class path ?? I may of course be completely wrong. Regards Felix
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Felix Meschberger wrote: Hi, Am Donnerstag, den 17.01.2008, 11:53 +0200 schrieb Jukka Zitting: Hi, On Jan 16, 2008 6:01 PM, Thomas Mueller [EMAIL PROTECTED] wrote: My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? In Jackrabbit we only use a fairly standard subset of XML functionality, mainly just parsing and serialization of relatively simple XML documents. I think the only real XML parser incompatibility issue we've faced is the xmlns serialization issue, and we have good workarounds for that. So I don't see us having many problems with using standard JAXP, and given the classloading horrors described by Carsten I would very much prefer sticking with standard JAXP. I am not totally fluent with the state nowadays: But hasn't there been a time, that Java 1.4 included a buggy Xerces version, which could only be replaced by hacking the boot class path ?? I may of course be completely wrong. Yes, 1.4 contains buggy Xerces versions (might be that latest 1.4 revisions are bug free), and no, it's not required to put the lib into the boot classpath. An own classloader which does parent last is sufficient. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, On Jan 17, 2008 11:57 AM, Felix Meschberger [EMAIL PROTECTED] wrote: I am not totally fluent with the state nowadays: But hasn't there been a time, that Java 1.4 included a buggy Xerces version, which could only be replaced by hacking the boot class path ?? I may of course be completely wrong. That may be the case, but we've never seen bug reports about that, so I don't think this matters to us. Without seeing actual issues with Jackrabbit and JAXP I think this parser incompatibility stuff is mostly just FUD. BR, Jukka Zitting
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560103#action_12560103 ] Padraic Hannon commented on JCR-1312: - All of our current CQ publish instances are currently CPU bound. So, while, XML performance may not be the central issue, anything we can do to reduce CPU overhead would be helpful for us here. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559414#action_12559414 ] Ian Boston commented on JCR-1312: - Also agree and have some more recent evidence. The benefits of SAX over DOM only become apparent when the DOM tree being created is large enough and hangs arround long enough to get out of the Eden GC if it does and the server is under extrem load, the GC processes will start to dominate and cause performance problems both on memory, and because of memory cpu. Although xpp is lightning fast and has much lower memory requirements than the parser used for both dom and sax, the cost of refactoring may well be excessive. When we rewrote the processing pipelines of a application (sakai) with lots of DOM processing, we also gathered the evidence through detailed profiling before doing anything. It was quite hard to get significant gains under load for fragments of 100 elements that hang around for less than 200ms, is most request cycles. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559427#action_12559427 ] angela commented on JCR-1312: - felix, what you were saying was: there is a performance/memory problem with DOM + Xerces. you didn't provide any figures so far. If we have a such problem, we should evaluate various possibilities and not just stay with the first proposal (which after all in a first test introduced a NullPointerException with very standard features). implications of possibly replacing DOM and have to admit, that it certainly is not worth it it would be some effort. but that doesn't mean a priori its not worth being evaluated. angela Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559429#action_12559429 ] Jukka Zitting commented on JCR-1312: I still don't see why we should have the alternative DocumentBuilder implemented within jackrabbit-webapp. JAXP already has a mechanism for specifying which XML parser to use. If there's a better XML parser available, then it should worry about implementing DocumentBuilder and correctly handling all the associated DOM semantics. I don't want to start seeing bug reports about our XML parser. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (JCR-1312) Get rid of DOM for XML support
Hi, My experience is that all XML parser are a little bit different. I don't know about you, but I did run into quite many problems because of XML parser incompatibilities. If we always use the same parser we would be sure we always get the same result on all systems. I believe that would be a big advantage, what do you think? Regards, Thomas
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559842#action_12559842 ] Felix Meschberger commented on JCR-1312: Jackrabbit is not an XML parser project. Definitely agreed on that one. Why doesn't kxml come with the DocumentBuilder implementation? Probably, they don't need it. But if you look at the patch, we are discussing three classes: * XmlPullDocumentBuilderFactory: A very simple class backed by a JAXP DocumentBuilderFactory * XmlPullDocumentBuilder: Also very simple, just one method of real complication, of which the most part is taken to guess the streams character encoding * DOM2XmlPullBuilder: The actual builder converting Pull Events to DOM. This class is copied from xmlpull.org * XmlPullDomSerializer: Straight forward and simple as well. IMHO given advantages (memory footprint (1% of Xerces) and performance (40-60% of Xerces)) this is probably a small price to pay :-) Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558999#action_12558999 ] angela commented on JCR-1312: - An alternative would be to use SAX instead of DOM. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559011#action_12559011 ] angela commented on JCR-1312: - The main issue is parsing i'm not sure about this one. the XML request bodies sent from a dav-client use to be small. in contrast the server may send a huge XML upon propfind or extract-properties-report. in this case i think SAX would be favorable. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1312) Get rid of DOM for XML support
[ https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559291#action_12559291 ] Julian Reschke commented on JCR-1312: - Totally agreed. Before making big changes, please first prove that there is a problem. In another WebDAV stack I worked on, the only place where we worked around DOM limitations was when constructing depth:infinity responses to SEARCH and PROPFIND, avoiding to have to keep the whole response in the DOM. That was it. Get rid of DOM for XML support -- Key: JCR-1312 URL: https://issues.apache.org/jira/browse/JCR-1312 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: Felix Meschberger Currently the web dav library uses Xerces and DOM to parse and create XML data. This mechanism is well-known but has two major issues: It is slow and it has a big memory footprint. In order to solve these two issues, I suggest to drop the use of the W3C DOM in webdav in favor of something easier and more straight forward to use. One candidate could be (out of my head and based on my bias towards KXml) KDOM. See also http://www.kxml.org.ww See also JCR-1261 for more discussions on this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
