Re: Jackrabbit roadmap
Torgeir Veimo wrote: * Node type management Sorry, meant * Built-in access control Based on this proposal? https://issues.apache.org/jira/browse/JCR-1171 There hasn't been any more comments on that issue for a while. i'm working on jsr 283 access control features and yes i'm using the code from JCR-1171 as basis, but the final code will most certainly be quite different. i will update the issue as soon as i have something to discuss about. angela
[jira] Commented: (JCR-1261) Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation
[ https://issues.apache.org/jira/browse/JCR-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558972#action_12558972 ] angela commented on JCR-1261: - i prefer the patch provided by jukka. if both - litmus test suite on simple server - the spi2dav = jcr-server setup don't reveal any problems, i would feel confident that the patch doesn't cause any problems. yukka, could you test your patch with both setups? thanks angela Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation --- Key: JCR-1261 URL: https://issues.apache.org/jira/browse/JCR-1261 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Affects Versions: 1.3.3 Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: JCR-1261.drop-xerces.patch, JCR-1261.patch, JCR-1261_2.patch Proposing to replace the current Xerces/JAXP based implementation of XML data unmarshalling and marshalling to be replaced by a MXP ([1]) based implementation. MXP is an implementation of the XML PullParser API [2] and provides a very mall footprint (120KB) and far better performance than Xerces (my tests showed around 50% performance increase over Xerces for both unmarshalling and marshalling, see also [3]). Why do I care ? I would like to include WebDAV functionality into Sling and bundle is with as little dependencies as possible ( the xpp3 lib might even be bundled into this project to minimize dependencies). In addition, I think XML (un)marshalling performance is crucial in any WebDAV solution. For this reason, this project can only win if we add a more performing library. [1] http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/ [2] http://www.xmlpull.org [3] http://www.extreme.indiana.edu/~aslom/xpp_sax2bench/results.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1311) Webdav: get rid of DOM usage
Webdav: get rid of DOM usage Key: JCR-1311 URL: https://issues.apache.org/jira/browse/JCR-1311 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: angela Priority: Minor see JCR-1261 for reasons posted by felix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1261) Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation
[ https://issues.apache.org/jira/browse/JCR-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1261. - Resolution: Won't Fix Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation --- Key: JCR-1261 URL: https://issues.apache.org/jira/browse/JCR-1261 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Affects Versions: 1.3.3 Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: JCR-1261.drop-xerces.patch, JCR-1261.patch, JCR-1261_2.patch Proposing to replace the current Xerces/JAXP based implementation of XML data unmarshalling and marshalling to be replaced by a MXP ([1]) based implementation. MXP is an implementation of the XML PullParser API [2] and provides a very mall footprint (120KB) and far better performance than Xerces (my tests showed around 50% performance increase over Xerces for both unmarshalling and marshalling, see also [3]). Why do I care ? I would like to include WebDAV functionality into Sling and bundle is with as little dependencies as possible ( the xpp3 lib might even be bundled into this project to minimize dependencies). In addition, I think XML (un)marshalling performance is crucial in any WebDAV solution. For this reason, this project can only win if we add a more performing library. [1] http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/ [2] http://www.xmlpull.org [3] http://www.extreme.indiana.edu/~aslom/xpp_sax2bench/results.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558988#action_12558988 ] angela commented on JCR-1310: - posted by jukka in JCR-1261: Anyway, going back to the original justification of this issue. Your first point was to minimize dependencies, which IMHO could be better achieved by just dropping the Xerces dependency in favor of standard JAXP (see also JCR-367). The attached patch (JCR-1261.drop-xerces.patch) does just that with trivial changes to the codebase. (Note that I haven't really tested the patch, there may be some subtle issues with JAXP serialization of namespaced DOM trees.) comment angela: if both - litmus test suite on simple server - the spi2dav = jcr-server setup don't reveal any problems, i would feel confident that the patch doesn't cause any problems. yukka, could you test your patch with both setups? thanks Webdav: Drop xerces dependency -- Key: JCR-1310 URL: https://issues.apache.org/jira/browse/JCR-1310 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: angela Priority: Minor Attachments: JCR-1261.drop-xerces.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1310) Webdav: Drop xerces dependency
[ https://issues.apache.org/jira/browse/JCR-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1310: Attachment: JCR-1261.drop-xerces.patch patch provided by jukka Webdav: Drop xerces dependency -- Key: JCR-1310 URL: https://issues.apache.org/jira/browse/JCR-1310 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: angela Priority: Minor Attachments: JCR-1261.drop-xerces.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ocm:discriminator
Hi Paddy, Has anyone given this more thought? If no one objects I'll open a Jira ticket and work on a patch, Thanks I think we could just use the mapping file and node type. This would mean we would loose the ability to map multiple classes to a single node type/mixin set, but I am unsure if that is such a bad thing anyway. In some applications, I would like to map all objects into nt:unstructured.
[jira] Commented: (JCR-1261) Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation
[ https://issues.apache.org/jira/browse/JCR-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558978#action_12558978 ] Felix Meschberger commented on JCR-1261: I don't think Jukka's patch matches the original intent of this issue, which was really concerned with performance. And while the JAXP XML parser library setup may work for your general out of the box application, I think it has serious shortcomings ... But this is another story ;-) How about postponing this issue and turn it into something like: Drop DOM for performance and memory footprint reasons. Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation --- Key: JCR-1261 URL: https://issues.apache.org/jira/browse/JCR-1261 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Affects Versions: 1.3.3 Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: JCR-1261.drop-xerces.patch, JCR-1261.patch, JCR-1261_2.patch Proposing to replace the current Xerces/JAXP based implementation of XML data unmarshalling and marshalling to be replaced by a MXP ([1]) based implementation. MXP is an implementation of the XML PullParser API [2] and provides a very mall footprint (120KB) and far better performance than Xerces (my tests showed around 50% performance increase over Xerces for both unmarshalling and marshalling, see also [3]). Why do I care ? I would like to include WebDAV functionality into Sling and bundle is with as little dependencies as possible ( the xpp3 lib might even be bundled into this project to minimize dependencies). In addition, I think XML (un)marshalling performance is crucial in any WebDAV solution. For this reason, this project can only win if we add a more performing library. [1] http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/ [2] http://www.xmlpull.org [3] http://www.extreme.indiana.edu/~aslom/xpp_sax2bench/results.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1261) Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation
[ https://issues.apache.org/jira/browse/JCR-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12558982#action_12558982 ] angela commented on JCR-1261: - How about postponing this issue and turn it into something like: Drop DOM for performance and memory footprint reasons. in order not to have lengthy issues, i would in this case prefer to close this one as won't fix an open new issues: 1) get rid of xerces dependency 2) drop DOM Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation --- Key: JCR-1261 URL: https://issues.apache.org/jira/browse/JCR-1261 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Affects Versions: 1.3.3 Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: JCR-1261.drop-xerces.patch, JCR-1261.patch, JCR-1261_2.patch Proposing to replace the current Xerces/JAXP based implementation of XML data unmarshalling and marshalling to be replaced by a MXP ([1]) based implementation. MXP is an implementation of the XML PullParser API [2] and provides a very mall footprint (120KB) and far better performance than Xerces (my tests showed around 50% performance increase over Xerces for both unmarshalling and marshalling, see also [3]). Why do I care ? I would like to include WebDAV functionality into Sling and bundle is with as little dependencies as possible ( the xpp3 lib might even be bundled into this project to minimize dependencies). In addition, I think XML (un)marshalling performance is crucial in any WebDAV solution. For this reason, this project can only win if we add a more performing library. [1] http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/ [2] http://www.xmlpull.org [3] http://www.extreme.indiana.edu/~aslom/xpp_sax2bench/results.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1310) Webdav: Drop xerces dependency
Webdav: Drop xerces dependency -- Key: JCR-1310 URL: https://issues.apache.org/jira/browse/JCR-1310 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: angela Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1311) Webdav: get rid of DOM usage
[ https://issues.apache.org/jira/browse/JCR-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed JCR-1311. -- Resolution: Duplicate Closing as duplicating JCR-1312 Webdav: get rid of DOM usage Key: JCR-1311 URL: https://issues.apache.org/jira/browse/JCR-1311 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Reporter: angela Priority: Minor see JCR-1261 for reasons posted by felix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1261) Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation
[ https://issues.apache.org/jira/browse/JCR-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed JCR-1261. -- Agreed. So I close this and created two new issues. JCR-1312. Oops, I see angela just went ahead So I closed JCR-1311 in favor my own JCR-1312 and do nothing for the dropping Xerces. Replace Xerces/JAXP based (un)marshalling by KXml2 based implementation --- Key: JCR-1261 URL: https://issues.apache.org/jira/browse/JCR-1261 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-webdav Affects Versions: 1.3.3 Reporter: Felix Meschberger Assignee: Felix Meschberger Attachments: JCR-1261.drop-xerces.patch, JCR-1261.patch, JCR-1261_2.patch Proposing to replace the current Xerces/JAXP based implementation of XML data unmarshalling and marshalling to be replaced by a MXP ([1]) based implementation. MXP is an implementation of the XML PullParser API [2] and provides a very mall footprint (120KB) and far better performance than Xerces (my tests showed around 50% performance increase over Xerces for both unmarshalling and marshalling, see also [3]). Why do I care ? I would like to include WebDAV functionality into Sling and bundle is with as little dependencies as possible ( the xpp3 lib might even be bundled into this project to minimize dependencies). In addition, I think XML (un)marshalling performance is crucial in any WebDAV solution. For this reason, this project can only win if we add a more performing library. [1] http://www.extreme.indiana.edu/xgws/xsoap/xpp/mxp1/ [2] http://www.xmlpull.org [3] http://www.extreme.indiana.edu/~aslom/xpp_sax2bench/results.html -- 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] Issue Comment Edited: (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 ] anchela edited comment on JCR-1312 at 1/15/08 1:52 AM: -- An alternative would be to use SAX instead of DOM... which would not require to add another dependency. was (Author: anchela): 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] Created: (JCR-1313) Additional excerpt provider implementation
Additional excerpt provider implementation -- Key: JCR-1313 URL: https://issues.apache.org/jira/browse/JCR-1313 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Fix For: 1.5 The current DefaultHTMLExcerpt implementation is very simple. It basically picks the first three fragments, regardless of how many matches it contains. There should be an alternative implementation that weights the fragments based on the number of matching terms and the whether phrases have matched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1313) Additional excerpt provider implementation
[ https://issues.apache.org/jira/browse/JCR-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1313. --- Resolution: Fixed Added WeightedXMLExcerpt and WeightedHTMLExcerpt in revision: 612123 Additional excerpt provider implementation -- Key: JCR-1313 URL: https://issues.apache.org/jira/browse/JCR-1313 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Fix For: 1.5 The current DefaultHTMLExcerpt implementation is very simple. It basically picks the first three fragments, regardless of how many matches it contains. There should be an alternative implementation that weights the fragments based on the number of matching terms and the whether phrases have matched. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1314) Node incorrectly overridden when performing a merge
Node incorrectly overridden when performing a merge
---
Key: JCR-1314
URL: https://issues.apache.org/jira/browse/JCR-1314
Project: Jackrabbit
Issue Type: Bug
Components: versioning
Affects Versions: 1.4, 1.5
Reporter: Bob Wieler
Priority: Critical
The implementation of the merge algorithm provided in the JCR specification is
incorrect and can result in nodes being overridden. This can be demonstrated by
the following simple steps:
1. Create a repository with a nt:file node containing whatever data (n')
2. Commit the changes to the node to create the initial version (v')
3. Copy the node to a new workspace
4. Edit the node in the second workspace (n)
5. Commit the changes to the second workspace to create the second version (v)
6. Merge the changes from the first workspace into the second workspace
According to the JCR specification (from 8.2.10.1):
if v' is a successor of v and n is not checked-in doupdate(n, n').
else if v is equal to or a predecessor of v' doleave(n).
else dofail(n, v').
In the above example, v' is a predecessor of v so the doupdate(n, n') is not
done. v and v' are also not equal and v is not a predecessor of v' so the
doleaven(n) is not done. Therefore the dofail(n, v') is what should be called.
The code in NodeImpl.java is not however doing what is expected. Line 3337 in
NodeImpl.java (subversion revision 611855) has the following:
} else if (v.isSame(vp) || v.isMoreRecent(vp)) {
// If V' is a predecessor (to any degree) of V or if V and V' are
// identical (i.e., are actually the same version), then the merge
// result for N is leave. This case can be thought of as the case
where
// N' is older or the same age as N and therefore N should be
left alone.
return null;
} else {
The doMergeTest method returns null (essentially a doleave(n) in the spec
algorithm) if v and v' are the same or v' is a predecessor to v - in other
words if v and v' are the same or v is a _successor_ to v' - which is exactly
the opposite to what the specification requires (if v is equal to or a
_predecessor_ of v'). The proper if statement would be to have:
} else if (v.isSame(vp) || vp.isMoreRecent(v)) {
Unfortunately, this was causing us to lose data when performing a merge. I have
updated our version of jackrabbit with the above change and merging now works
as expected.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1315) Add Google Analytics to Jackrabbit web site
Add Google Analytics to Jackrabbit web site --- Key: JCR-1315 URL: https://issues.apache.org/jira/browse/JCR-1315 Project: Jackrabbit Issue Type: Task Components: jackrabbit-site Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: none I'd like to add Google Analytics to our web site to better track how the site is used and how much traffic we are generating. Currently the best stats we have are at http://people.apache.org/~vgritsenko/stats/projects/jackrabbit.html, which is nice but not nearly as good as we could have. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1315) Add Google Analytics to Jackrabbit web site
[ https://issues.apache.org/jira/browse/JCR-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1315. Resolution: Fixed Google Analytics added in revision 612189 and will go to the live site later today before the 1.4 announcement. Add Google Analytics to Jackrabbit web site --- Key: JCR-1315 URL: https://issues.apache.org/jira/browse/JCR-1315 Project: Jackrabbit Issue Type: Task Components: jackrabbit-site Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: none I'd like to add Google Analytics to our web site to better track how the site is used and how much traffic we are generating. Currently the best stats we have are at http://people.apache.org/~vgritsenko/stats/projects/jackrabbit.html, which is nice but not nearly as good as we could have. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[OCM] ocm cache
There is a simple OCM cache which I would like to remove or at least make optional. Currently there is already a lot of caching going on within jackrabbit and the current cache implementation for OCM is extremely simplistic. For example, if a node changes under the OCM it has no knowledge of this and the cache is not flushed. Until there is robust support for observation and a more plug-able architecture the OCM cache seems like it is more dangerous than helpful. WDYT? paddy
[jira] Commented: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559243#action_12559243 ] Padraic Hannon commented on JCR-872: Until we have a robust cache framework we should remove the current implementation as it poses some problems the two that I've run into are: 1) Unbounded HashMap with no size limits 2) No observation mechanism to detect underlying changes to jcr nodes Cache framework integration --- Key: JCR-872 URL: https://issues.apache.org/jira/browse/JCR-872 Project: Jackrabbit Issue Type: Task Components: jackrabbit-ocm Reporter: Christophe Lombart The PersistenceManager should work with a cache manager. * The Spring frameworks offer a nice solution to integrate an application with a cache manager (based on AOP). * Which cache framework to use ? oscache, JCS, ... * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1280) Path.equals does not work for other Path implementations
[ https://issues.apache.org/jira/browse/JCR-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559281#action_12559281 ] Julian Reschke commented on JCR-1280: - Of course there are. One of the reasons for the introduction of the new APIs was to allow implementations to use custom Name/Path implementations. In particular, for some implementations it will be more efficient to store (prefix, localName), others will prefer (namespace, localname). Path.equals does not work for other Path implementations Key: JCR-1280 URL: https://issues.apache.org/jira/browse/JCR-1280 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-spi-commons Reporter: Julian Reschke Assignee: Julian Reschke PathImpl.equals does not take other path implementations into account (likely a typo). -- 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.
[jira] Updated: (JCR-872) Cache framework integration
[ https://issues.apache.org/jira/browse/JCR-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Padraic Hannon updated JCR-872: --- Attachment: observableCache.patch This patch provides the following: 1) Updates to RequestObjectCacheImpl to provide observation to flush based on jcr events 2) Updates ObjectCache interface to extend Map (first step in allowing other caches) 3) Provides the ability to set the cache on the ObjectContentManager and have that ripple to the ObjectConverterImpl (so we can use a config file to set cache after construction of the content manager) 4) Simple cache unit tests I was going to go down the hibernate cache provider route, but felt it was a bit overkill. Tomorrow I will create instances of the cache using EhCache. From there I think I will try a Tangosol one. Cache framework integration --- Key: JCR-872 URL: https://issues.apache.org/jira/browse/JCR-872 Project: Jackrabbit Issue Type: Task Components: jackrabbit-ocm Reporter: Christophe Lombart Attachments: observableCache.patch The PersistenceManager should work with a cache manager. * The Spring frameworks offer a nice solution to integrate an application with a cache manager (based on AOP). * Which cache framework to use ? oscache, JCS, ... * A more detailled proposal is required -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
