[jira] Resolved: (JCR-568) incorrect jcr:uuid on frozen subnode

[ http://issues.apache.org/jira/browse/JCR-568?page=all ] Jukka Zitting resolved JCR-568. --- Resolution: Fixed > incorrect jcr:uuid on frozen subnode > > > Key: JCR-568 > URL: http://issues

[jira] Updated: (JCR-568) incorrect jcr:uuid on frozen subnode

[ http://issues.apache.org/jira/browse/JCR-568?page=all ] Jukka Zitting updated JCR-568: -- Fix Version/s: 1.1.1 (was: 1.1) Affects Version/s: 0.9 1.0 1.0.1 > incorrect jcr:uuid

[jira] Reopened: (JCR-568) incorrect jcr:uuid on frozen subnode

[ http://issues.apache.org/jira/browse/JCR-568?page=all ] Jukka Zitting reopened JCR-568: --- Reopening to target for 1.1.1 > incorrect jcr:uuid on frozen subnode > > > Key: JCR-568 >

[jira] Updated: (JCR-586) Removing a mixin that adds a same-name-sibling child node throws an ItemNotFoundException

[ http://issues.apache.org/jira/browse/JCR-586?page=all ] Jukka Zitting updated JCR-586: -- Fix Version/s: 1.1.1 > Removing a mixin that adds a same-name-sibling child node throws an > ItemNotFoundException > -

[jira] Resolved: (JCR-651) Improve performance for queries with large result sets

[ http://issues.apache.org/jira/browse/JCR-651?page=all ] Marcel Reutegger resolved JCR-651. -- Fix Version/s: 1.2 Resolution: Fixed Nodes in the query result are now fetched in chunks. The initial chunk can be configured with the parameter 'resul

[jira] Created: (JCR-651) Improve performance for queries with large result sets

Improve performance for queries with large result sets -- Key: JCR-651 URL: http://issues.apache.org/jira/browse/JCR-651 Project: Jackrabbit Issue Type: Improvement Affects Versions: 0.

[jira] Commented: (JCR-647) NodeType.canRemoveItem does not consider residual definitions (JCR2SPI)

[ http://issues.apache.org/jira/browse/JCR-647?page=comments#action_12454017 ] angela commented on JCR-647: the patch looks good to me. however: the code originates from jackrabbit.core.nodetype.EffectiveNodeType.java and probably stefan knows more

[jira] Commented: (JCR-612) Restructure the Jackrabbit source tree

[ http://issues.apache.org/jira/browse/JCR-612?page=comments#action_12453987 ] Jan Kuzniak commented on JCR-612: - I have just ripped out jackrabbit-api and jackrabbit-commons and jackrabbit-core out of jackrabbit artifact (that is now empty). It

Re: JCR & Jackrabbit presentation

Hi Christophe, Before starting my own presentation slides, are there somewhere good slides on JCR & Jackrabbit (powerpoint, ...). This is for a technical team. Yes I'm lazy :-) Try this: http://www.day.com/o.file/cmf-2006.pdf?get=073d75dc38e1f3af470652f5e9086972 This is a preso I used recently

JCR & Jackrabbit presentation

Hi all, I would like to make a presentation on JCR & Jackrabbit to an important european organisation. They would like to evaluate several products/approach to redesign their publication system. Before starting my own presentation slides, are there somewhere good slides on JCR & Jackrabbit (powe

[jira] Updated: (JCR-650) SimpleJbossAccessManager

[ http://issues.apache.org/jira/browse/JCR-650?page=all ] Darren Hartford updated JCR-650: Attachment: pom.xml > SimpleJbossAccessManager > > > Key: JCR-650 > URL: http://issues.apache.org/jira/bro

[jira] Updated: (JCR-650) SimpleJbossAccessManager

[ http://issues.apache.org/jira/browse/JCR-650?page=all ] Darren Hartford updated JCR-650: Attachment: SimpleJbossAccessManager.java > SimpleJbossAccessManager > > > Key: JCR-650 > URL: http://issu

[jira] Created: (JCR-650) SimpleJbossAccessManager

SimpleJbossAccessManager Key: JCR-650 URL: http://issues.apache.org/jira/browse/JCR-650 Project: Jackrabbit Issue Type: New Feature Components: security Affects Versions: 1.1 Environment: Jboss

Re: Import in versionStorage

On 11/27/06, Nicolas <[EMAIL PROTECTED]> wrote: Hi Florent, What you describe is one of the backup tool use case. I am adding the last touch to it so it can be committed it by hopefully next week (there is jut a well, that might be a bit overoptimistic... cheers stefan few home cleaning tas

[jira] Commented: (JCR-600) Repository does not release all resources on shutdown

[ http://issues.apache.org/jira/browse/JCR-600?page=comments#action_12453875 ] Torgeir Veimo commented on JCR-600: --- I tried with both a 1.1 with the patches attached, and a fresh svn snapshot from Nov 28th 06, and I still see permgen growing w

[jira] Resolved: (JCR-649) Like expression does not match line terminator in String

[ http://issues.apache.org/jira/browse/JCR-649?page=all ] Marcel Reutegger resolved JCR-649. -- Resolution: Fixed Fixed in revision: 479968 > Like expression does not match line terminator in String > -

Re: maven build problem of svn source

Hi, On 11/28/06, Torgeir Veimo <[EMAIL PROTECTED]> wrote: I'm still having problem building the current svn source. The javacc compiler seems to have encoding issues. Does anyone more familiar with maven have an idea what is wrong? I've tried setting my LANG env, but I don't think javacc picks u

[jira] Created: (JCR-649) Like expression does not match line terminator in String

Like expression does not match line terminator in String Key: JCR-649 URL: http://issues.apache.org/jira/browse/JCR-649 Project: Jackrabbit Issue Type: Bug Components: query

maven build problem of svn source

I'm still having problem building the current svn source. The javacc compiler seems to have encoding issues. Does anyone more familiar with maven have an idea what is wrong? I've tried setting my LANG env, but I don't think javacc picks up that in any case.. [EMAIL PROTECTED] jackrabbit]$ /usr/jav

Re: Query performance for large query results

Hi, On 11/28/06, Thomas Mueller <[EMAIL PROTECTED]> wrote: Anyway, from an API / user perspective, setLimit and setOffset are often used together, for paging. And in many cases the underlying engine can be implemented more efficiently when it knows the offset and the actual number of elements th

Re: Query performance for large query results

Hi, I didn't know that checking access rights is so expensive... For me, checking access rights doesn't 'sound' like it should be a performance problem. But I think I understand why it is at the moment. I hope that at some point we can find a solution to speed this up or delegate it to the search

Re: Query performance for large query results

Thomas Mueller wrote: My reason to ask for setOffset was, I was hoping the performance can optimized more easily. Skip needs to be called after getNodes. If getNodes already 'knows' before how many nodes will be skipped, then it may be easier to optimize getNodes (in the future). Of course this i