[jira] Commented: (JCR-642) Support flat content hierarchies
[ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738228#action_12738228 ] Jukka Zitting commented on JCR-642: --- Do you think it is necessary to break the NodeState or PersistenceManager interfaces? Yes. NodeState is currently a class that's pretty difficult to subclass, and the PersistenceManager interface refers to it directly. If we change that (make NodeState an interface), we can just as well adjust the interfaces to better support the needs of this issue. Support flat content hierarchies Key: JCR-642 URL: https://issues.apache.org/jira/browse/JCR-642 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns. These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times. In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node. To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2235) Set binary property data using OutputStream
[ https://issues.apache.org/jira/browse/JCR-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738237#action_12738237 ] Jukka Zitting commented on JCR-2235: Do you have a use case for this? The implementation of PipedStream.write() would still need some source from which it reads the data that then gets written to the OutputStream. Wouldn't it be simpler to use an InputStream wrapper for that source? The only case I can think of where an extra thread is needed is with event-based systems like SAX. This also seems like something that would fit better in a general-purpose library like Commons IO. Set binary property data using OutputStream --- Key: JCR-2235 URL: https://issues.apache.org/jira/browse/JCR-2235 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-jcr-commons Reporter: Marcel Reutegger Attachments: JCR-2235.patch This is a helper class that allows to write binary data into an output stream which is piped into an input stream that can be provided to the methods Node.setProperty(String, InputStream), ValueFactory.createBinary(InputStream) or Property.setValue(InputStream). This class may help to avoid creating a temporary file that contains the data that will be set. Instead of streaming the data from a temp file, the data can be written directly into the repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2237) ItemManager registers itself as listener too early
ItemManager registers itself as listener too early -- Key: JCR-2237 URL: https://issues.apache.org/jira/browse/JCR-2237 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Marcel Reutegger Priority: Minor This is similar to JCR-2168 but for ItemManager and SessionItemStateManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2231) Avoid item state reads during Session.logout()
[ https://issues.apache.org/jira/browse/JCR-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-2231: --- Component/s: jackrabbit-core Avoid item state reads during Session.logout() -- Key: JCR-2231 URL: https://issues.apache.org/jira/browse/JCR-2231 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Marcel Reutegger Priority: Minor Fix For: 2.0.0 Attachments: JCR-2231.patch Local item states are discarded during Session.logout(). Currently the CachingHierarchyManager is still registered as a item state listener at that time and will cause numerous ItemStateManager.hasItemState() calls. This is unnecessary and just adds overhead to the logout call. In addition it will also contribute to a potential lock contention on the SharedItemStateManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2237) ItemManager registers itself as listener too early
[ https://issues.apache.org/jira/browse/JCR-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-2237: -- Attachment: JCR-2237.patch Proposed patch. ItemManager registers itself as listener too early -- Key: JCR-2237 URL: https://issues.apache.org/jira/browse/JCR-2237 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Marcel Reutegger Priority: Minor Attachments: JCR-2237.patch This is similar to JCR-2168 but for ItemManager and SessionItemStateManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2237) ItemManager registers itself as listener too early
[ https://issues.apache.org/jira/browse/JCR-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-2237: -- Status: Patch Available (was: Open) ItemManager registers itself as listener too early -- Key: JCR-2237 URL: https://issues.apache.org/jira/browse/JCR-2237 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.0 Reporter: Marcel Reutegger Priority: Minor Attachments: JCR-2237.patch This is similar to JCR-2168 but for ItemManager and SessionItemStateManager. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-642) Support flat content hierarchies
[ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738292#action_12738292 ] Thomas Mueller commented on JCR-642: I would (try to) use the b-tree data structure: http://en.wikipedia.org/wiki/B-tree I would keep the internal implementation (PersistenceManagerAPI, NodeState and so on), but add a property 'hidden' to node (maybe using an empty name). Hidden nodes would have no properties, only child nodes. When adding a child to a hidden node X, the child would be added to a child of X, and the b-tree would be re-balanced. The same when removing a child from a hidden node. Other than that, user-facing algorithms would need to be changed, specially getPath, and NodeIterator. Basically hidden nodes would never be returned to the application and not be directly accessible using the JCR API. Support flat content hierarchies Key: JCR-642 URL: https://issues.apache.org/jira/browse/JCR-642 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns. These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times. In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node. To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2085) test case (TCK) maintenance for JCR 2.0
[ https://issues.apache.org/jira/browse/JCR-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated JCR-2085: Attachment: apicoverage.html API coverage as of Aug 03: 520/522 = ~99% test case (TCK) maintenance for JCR 2.0 --- Key: JCR-2085 URL: https://issues.apache.org/jira/browse/JCR-2085 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 2.0.0 Attachments: apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, jcrtests-binary.patch, jcrtests-versioning-2.patch, jcrtests-versioning.patch Umbrella issue for changes/additions to JUnit test cases, setup and config. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2238) Binary throws NullPointerException
Binary throws NullPointerException --- Key: JCR-2238 URL: https://issues.apache.org/jira/browse/JCR-2238 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Reporter: Marcel Reutegger Precondition: repository with datastore disabled! Steps to reproduce: 1) create binary from stream 2) set binary on property 3) dispose binary 4) get binary from property and dispose it immediately 5) go to 4) Binary.dispose() will throw a NullPointerException when 4) is executed the second time. The exception is not thrown if the property is saved after 2). See also attached test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2239) NPE during commit
NPE during commit - Key: JCR-2239 URL: https://issues.apache.org/jira/browse/JCR-2239 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.7 Environment: Spring Modules 0.9 Reporter: Yoav Landman Priority: Critical This seems to be a similar issue to JCR-2168. This time, it is the ItemManager that is registered on SessionItemStateManager before its construction completed, resulting in the following NPE. Once this happens, all transactions are frozen (IIRC, DefaultISMLocking#acquireWriteLock is blocked, but I lost the original thread-dump). Caused by: java.lang.NullPointerException: null at org.apache.jackrabbit.core.ItemManager.retrieveItem(ItemManager.java:743) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.ItemManager.stateCreated(ItemManager.java:927) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:812) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:390) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:235) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:310) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:739) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:183) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:206) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339) [jackrabbit-core-1.5.7.jar:na] at org.springframework.extensions.jcr.jackrabbit.support.JackRabbitUserTransaction.commit(JackRabbitUserTransaction.java:95) [se-jcr-0.9.jar:na] at org.springframework.extensions.jcr.jackrabbit.LocalTransactionManager.doCommit(LocalTransactionManager.java:189) [se-jcr-0.9.jar:na] ... 13 common frames omitted -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSR 283 implementation in PHP
Hi, On Thu, Jul 30, 2009 at 7:02 PM, Philip Arkcollphi...@knowledgetree.com wrote: ...We're considering implementing a JSR 283 CR in PHP 5 and releasing this under the Apache license. We're aware of early projects aimed at developing a JSR 170 CR. Are you aware of any current efforts to do so?... There's Jackalope, http://blog.liip.ch/archive/2009/05/12/jackalope-started.html , not sure if they target JSR 170 or 283. -Bertrand
[jira] Updated: (JCR-2239) NPE during commit
[ https://issues.apache.org/jira/browse/JCR-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yoav Landman updated JCR-2239: -- Attachment: commit-npe.patch Attached proposed patch NPE during commit - Key: JCR-2239 URL: https://issues.apache.org/jira/browse/JCR-2239 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.7 Environment: Spring Modules 0.9 Reporter: Yoav Landman Priority: Critical Attachments: commit-npe.patch This seems to be a similar issue to JCR-2168. This time, it is the ItemManager that is registered on SessionItemStateManager before its construction completed, resulting in the following NPE. Once this happens, all transactions are frozen (IIRC, DefaultISMLocking#acquireWriteLock is blocked, but I lost the original thread-dump). Caused by: java.lang.NullPointerException: null at org.apache.jackrabbit.core.ItemManager.retrieveItem(ItemManager.java:743) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.ItemManager.stateCreated(ItemManager.java:927) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:812) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:390) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:235) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:310) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:739) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:183) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:206) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339) [jackrabbit-core-1.5.7.jar:na] at org.springframework.extensions.jcr.jackrabbit.support.JackRabbitUserTransaction.commit(JackRabbitUserTransaction.java:95) [se-jcr-0.9.jar:na] at org.springframework.extensions.jcr.jackrabbit.LocalTransactionManager.doCommit(LocalTransactionManager.java:189) [se-jcr-0.9.jar:na] ... 13 common frames omitted -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-2239) NPE during commit
[ https://issues.apache.org/jira/browse/JCR-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-2239. --- Resolution: Duplicate NPE during commit - Key: JCR-2239 URL: https://issues.apache.org/jira/browse/JCR-2239 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.7 Environment: Spring Modules 0.9 Reporter: Yoav Landman Priority: Critical Attachments: commit-npe.patch This seems to be a similar issue to JCR-2168. This time, it is the ItemManager that is registered on SessionItemStateManager before its construction completed, resulting in the following NPE. Once this happens, all transactions are frozen (IIRC, DefaultISMLocking#acquireWriteLock is blocked, but I lost the original thread-dump). Caused by: java.lang.NullPointerException: null at org.apache.jackrabbit.core.ItemManager.retrieveItem(ItemManager.java:743) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.ItemManager.stateCreated(ItemManager.java:927) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:812) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:390) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:235) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:310) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:739) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:183) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:206) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339) [jackrabbit-core-1.5.7.jar:na] at org.springframework.extensions.jcr.jackrabbit.support.JackRabbitUserTransaction.commit(JackRabbitUserTransaction.java:95) [se-jcr-0.9.jar:na] at org.springframework.extensions.jcr.jackrabbit.LocalTransactionManager.doCommit(LocalTransactionManager.java:189) [se-jcr-0.9.jar:na] ... 13 common frames omitted -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-2238) Binary throws NullPointerException
[ https://issues.apache.org/jira/browse/JCR-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-2238: -- Attachment: BinaryValueTest.patch Binary throws NullPointerException --- Key: JCR-2238 URL: https://issues.apache.org/jira/browse/JCR-2238 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Reporter: Marcel Reutegger Attachments: BinaryValueTest.patch Precondition: repository with datastore disabled! Steps to reproduce: 1) create binary from stream 2) set binary on property 3) dispose binary 4) get binary from property and dispose it immediately 5) go to 4) Binary.dispose() will throw a NullPointerException when 4) is executed the second time. The exception is not thrown if the property is saved after 2). See also attached test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2239) NPE during commit
[ https://issues.apache.org/jira/browse/JCR-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738305#action_12738305 ] Yoav Landman commented on JCR-2239: --- Well, it is certainly not minor, since our application is dead once we get this exception... NPE during commit - Key: JCR-2239 URL: https://issues.apache.org/jira/browse/JCR-2239 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 1.5.7 Environment: Spring Modules 0.9 Reporter: Yoav Landman Priority: Critical Attachments: commit-npe.patch This seems to be a similar issue to JCR-2168. This time, it is the ItemManager that is registered on SessionItemStateManager before its construction completed, resulting in the following NPE. Once this happens, all transactions are frozen (IIRC, DefaultISMLocking#acquireWriteLock is blocked, but I lost the original thread-dump). Caused by: java.lang.NullPointerException: null at org.apache.jackrabbit.core.ItemManager.retrieveItem(ItemManager.java:743) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.ItemManager.stateCreated(ItemManager.java:927) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SessionItemStateManager.stateCreated(SessionItemStateManager.java:812) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.LocalItemStateManager.stateCreated(LocalItemStateManager.java:428) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateCreated(StateChangeDispatcher.java:96) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SharedItemStateManager.stateCreated(SharedItemStateManager.java:390) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.ItemState.notifyStateCreated(ItemState.java:235) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:310) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:739) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.state.XAItemStateManager.commit(XAItemStateManager.java:183) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.TransactionContext.commit(TransactionContext.java:206) [jackrabbit-core-1.5.7.jar:na] at org.apache.jackrabbit.core.XASessionImpl.commit(XASessionImpl.java:339) [jackrabbit-core-1.5.7.jar:na] at org.springframework.extensions.jcr.jackrabbit.support.JackRabbitUserTransaction.commit(JackRabbitUserTransaction.java:95) [se-jcr-0.9.jar:na] at org.springframework.extensions.jcr.jackrabbit.LocalTransactionManager.doCommit(LocalTransactionManager.java:189) [se-jcr-0.9.jar:na] ... 13 common frames omitted -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-2085) test case (TCK) maintenance for JCR 2.0
[ https://issues.apache.org/jira/browse/JCR-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738306#action_12738306 ] Jukka Zitting commented on JCR-2085: Looks promising! The only methods with no TCK tests touching them are: VersionManager.merge(String, String, boolean, boolean) VersionManager.merge(Node) test case (TCK) maintenance for JCR 2.0 --- Key: JCR-2085 URL: https://issues.apache.org/jira/browse/JCR-2085 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-jcr-tests Reporter: Julian Reschke Assignee: Julian Reschke Fix For: 2.0.0 Attachments: apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, apicoverage.html, jcrtests-binary.patch, jcrtests-versioning-2.patch, jcrtests-versioning.patch Umbrella issue for changes/additions to JUnit test cases, setup and config. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-2240) Binary value may leave temp file behind
Binary value may leave temp file behind --- Key: JCR-2240 URL: https://issues.apache.org/jira/browse/JCR-2240 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Reporter: Marcel Reutegger The following call leaves a temp file behind that is never deleted: InputStream in = ... ValueFactory vf = vf.createBinary(in).dispose(); Only happens when the datastore is disabled. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-642) Support flat content hierarchies
[ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738316#action_12738316 ] Bart van der Schans commented on JCR-642: - Would it be an idea to store the hierarchical information in a separate table with only (node_id, parent_id)? That way if you would add or remove a node to/from a large child node list no serialization of the complete child node list would be needed at the cost of doing one simple extra query. I would also make it easier to lazy initialize the child node list, because it wouldn't be part of the bundle de-serialization when loading the bundles from the database. Support flat content hierarchies Key: JCR-642 URL: https://issues.apache.org/jira/browse/JCR-642 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns. These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times. In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node. To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-642) Support flat content hierarchies
[ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738318#action_12738318 ] Thomas Mueller commented on JCR-642: hierarchical information in a separate table That's possible, but it would be quite a big change. Also, most likely it would be slower and would need more space. Support flat content hierarchies Key: JCR-642 URL: https://issues.apache.org/jira/browse/JCR-642 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns. These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times. In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node. To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-642) Support flat content hierarchies
[
https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738323#action_12738323
]
Stefan Guggisberg commented on JCR-642:
---
@bart;
Would it be an idea to store the hierarchical information in a separate table
with only (node_id, parent_id)?
yes, that would be the obvious approach for db-based pm's.
some random thoughts:
- you'd need a 3rd column ('name')
- you'd need a 4rd column (e.g. 'pos', in order to support ordered child nodes)
- read performance would suffer, especially for remote db's (2+ instead of 1 db
access)
- write performance would suffer (updating/reorganizing indices of very large
tables
can be very expensive)
- same-name sibling support would be a challenge (both implementation and
performance-wise)
- Node.hasNode() e.g. would be significantly slower
Support flat content hierarchies
Key: JCR-642
URL: https://issues.apache.org/jira/browse/JCR-642
Project: Jackrabbit Content Repository
Issue Type: Improvement
Components: jackrabbit-core
Reporter: Jukka Zitting
The current best practice with Jackrabbit is to avoid flat content structures
due to performance concerns.
These concerns are caused by the fact that the NodeState implementation
requires the list of child node names and identifiers to be available at all
times. In fact many (all?) current persistence managers implement this
requirement by storing and loading this list as a part of the serialized node
state. When this list grows, the performance and memory overhead of managing
the list grows as well. As a side note, this also creates potential
consistency issues since the parent/child links are stored both within the
child list of the parent node and as the parent link of the child node.
To solve this issue, I believe we need to break the tight bonding between the
node state and the list of child nodes. This will likely require major
refactoring of the Jackrabbit core, including breaking the NodeState and
PersistenceManager interfaces, so I don't expect a solution in near future.
However, we should start thinking about how to best do this, and at least be
concerned about building in any more assumptions about the list of child
nodes always being readily available.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-642) Support flat content hierarchies
[ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738327#action_12738327 ] Bart van der Schans commented on JCR-642: - @Thomas, Stefan, Thanks for your answerers! Obviously I need to give it a lot more thought... Bart. Support flat content hierarchies Key: JCR-642 URL: https://issues.apache.org/jira/browse/JCR-642 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns. These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times. In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node. To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1972: --- Attachment: JCR-1972_1.x.patch Thanks! I made some modifications to the patch (no tabs, less extra methods, even less code duplication; see attached patch for details) and committed it to the 1.x branch in revision 800385. I'll see what it takes to forward port this to the trunk. Preserving UUID and document version history on repository migration Key: JCR-1972 URL: https://issues.apache.org/jira/browse/JCR-1972 Project: Jackrabbit Content Repository Issue Type: Wish Components: jackrabbit-core Affects Versions: core 1.4.8 Reporter: Paco Avila Assignee: Jukka Zitting Attachments: Jackrabbit_modifications.pdf, JCR-1972.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch I have been working I an migration utility for OpenKM and I performed some changes in jackrabit-core to enable version import, preserving the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to preserve UUID in the migration process. This migration process is needed because there are changes in repository node definition, and Jackrabbit can't deal with this actually. I've attache a PDF with the changes needed in Jackrabbit-core. It works and there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738363#action_12738363 ] Jukka Zitting commented on JCR-1972: One more thing... Your patch referenced a CheckinCalendarTest class, but the relevant java file wasn't included in the patch. Can you attach the file so we can include it in the test suite? Preserving UUID and document version history on repository migration Key: JCR-1972 URL: https://issues.apache.org/jira/browse/JCR-1972 Project: Jackrabbit Content Repository Issue Type: Wish Components: jackrabbit-core Affects Versions: core 1.4.8 Reporter: Paco Avila Assignee: Jukka Zitting Attachments: Jackrabbit_modifications.pdf, JCR-1972.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch I have been working I an migration utility for OpenKM and I performed some changes in jackrabit-core to enable version import, preserving the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to preserve UUID in the migration process. This migration process is needed because there are changes in repository node definition, and Jackrabbit can't deal with this actually. I've attache a PDF with the changes needed in Jackrabbit-core. It works and there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-642) Support flat content hierarchies
[ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738376#action_12738376 ] Lars Trieloff commented on JCR-642: --- Thomas, do I see it right that introducing hidden nodes would mean only small effort is required to change existing persistence managers? And if we only introduce hidden nodes once we have more child nodes than we would put into a node in the B-Tree, there would be no performance impact for deep and thin trees, right? Support flat content hierarchies Key: JCR-642 URL: https://issues.apache.org/jira/browse/JCR-642 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns. These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times. In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node. To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-642) Support flat content hierarchies
[ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738386#action_12738386 ] Thomas Mueller commented on JCR-642: hidden nodes would mean only small effort is required to change existing persistence managers? There would be no change to the persistence manager! ...unfortunately, quite a lot of effort elsewhere in the core. no performance impact for deep and thin trees, right? The performance impact would be minimal (probably not measurable). Support flat content hierarchies Key: JCR-642 URL: https://issues.apache.org/jira/browse/JCR-642 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns. These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times. In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node. To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-642) Support flat content hierarchies
[ https://issues.apache.org/jira/browse/JCR-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738396#action_12738396 ] Lars Trieloff commented on JCR-642: --- There would be no change to the persistence manager! ...unfortunately, quite a lot of effort elsewhere in the core. I think that's the best news I have heard on this issue in a long time. We do not have to - break APIs - break existing third-party code - break existing persisted repositories Once we fix it, it is only an incremental change for existing users with long lists - their B-Tree that they did not know about will be re-balanced with the next write and that's it. Support flat content hierarchies Key: JCR-642 URL: https://issues.apache.org/jira/browse/JCR-642 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core Reporter: Jukka Zitting The current best practice with Jackrabbit is to avoid flat content structures due to performance concerns. These concerns are caused by the fact that the NodeState implementation requires the list of child node names and identifiers to be available at all times. In fact many (all?) current persistence managers implement this requirement by storing and loading this list as a part of the serialized node state. When this list grows, the performance and memory overhead of managing the list grows as well. As a side note, this also creates potential consistency issues since the parent/child links are stored both within the child list of the parent node and as the parent link of the child node. To solve this issue, I believe we need to break the tight bonding between the node state and the list of child nodes. This will likely require major refactoring of the Jackrabbit core, including breaking the NodeState and PersistenceManager interfaces, so I don't expect a solution in near future. However, we should start thinking about how to best do this, and at least be concerned about building in any more assumptions about the list of child nodes always being readily available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1972. Resolution: Fixed Fix Version/s: 1.6.0 The new method signatures are now available also in trunk. Resolving as fixed for 1.6.0. Preserving UUID and document version history on repository migration Key: JCR-1972 URL: https://issues.apache.org/jira/browse/JCR-1972 Project: Jackrabbit Content Repository Issue Type: Wish Components: jackrabbit-core Affects Versions: core 1.4.8 Reporter: Paco Avila Assignee: Jukka Zitting Fix For: 1.6.0 Attachments: Jackrabbit_modifications.pdf, JCR-1972.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch I have been working I an migration utility for OpenKM and I performed some changes in jackrabit-core to enable version import, preserving the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to preserve UUID in the migration process. This migration process is needed because there are changes in repository node definition, and Jackrabbit can't deal with this actually. I've attache a PDF with the changes needed in Jackrabbit-core. It works and there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JSR 283 implementation in PHP
Hi Alex, On Fri, Jul 31, 2009 at 11:38 AM, Alexander Klimetschek aklim...@day.comwrote: On Thu, Jul 30, 2009 at 7:02 PM, Philip Arkcollphi...@knowledgetree.com wrote: We're considering implementing a JSR 283 CR in PHP 5 and releasing this under the Apache license. We're aware of early projects aimed at developing a JSR 170 CR. Are you aware of any current efforts to do so? Would this be something the Jackrabbit community would be interested in getting involved in? Typo3 made some efforts of implementing first a PHP to JCR bridge (using Jackrabbit as backend) and the implementing JCR in PHP natively. See this blog post with some links: [1]. But I don't know whether they aim JSR-170 or 283 at the moment. It looks like the Typo3 effort has been spun off into a separate project, Flow3, covering a JSR-283 CR and allied framework. They've picked up on the dormant Jackrabbit port to PHP and appear to be actively working on it. http://flow3.typo3.org/ I cannot speak for the whole community, but I'd say the current focus lies on getting JSR-283 done in Jackrabbit. Implementing the full spec is quite a big task, so I'd recommend to start with selected areas only (eg. no observation, search, nodetype support etc.) to get you going. Fair enough. Thanks for the advice! Best regards, Philip [1] http://dev.day.com/microsling/content/blogs/main/fudbusting2.html Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
Re: JSR 283 implementation in PHP
On Mon, Aug 3, 2009 at 1:49 PM, Bertrand Delacretaz bdelacre...@apache.orgwrote: We're aware of early projects aimed at developing a JSR 170 CR. Are you aware of any current efforts to do so?... There's Jackalope, http://blog.liip.ch/archive/2009/05/12/jackalope-started.html , not sure if they target JSR 170 or 283. Thanks, Bertrand. We've come across Flow 3 and are investigating further. http://flow3.typo3.org/ Best regards, Philip
[jira] Commented: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12738544#action_12738544 ] Paco Avila commented on JCR-1972: - Sorry for the missing test class. I did no review of the generated patch and thought it was included. I'm on holiday but i will try to get a decent Internet connection to attach the missing class. Preserving UUID and document version history on repository migration Key: JCR-1972 URL: https://issues.apache.org/jira/browse/JCR-1972 Project: Jackrabbit Content Repository Issue Type: Wish Components: jackrabbit-core Affects Versions: core 1.4.8 Reporter: Paco Avila Assignee: Jukka Zitting Fix For: 1.6.0 Attachments: Jackrabbit_modifications.pdf, JCR-1972.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch I have been working I an migration utility for OpenKM and I performed some changes in jackrabit-core to enable version import, preserving the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to preserve UUID in the migration process. This migration process is needed because there are changes in repository node definition, and Jackrabbit can't deal with this actually. I've attache a PDF with the changes needed in Jackrabbit-core. It works and there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ANNOUNCE] Apache Jackrabbit 1.5.7 released
The Apache Jackrabbit community is pleased to announce the release of Apache Jackrabbit version 1.5.7. The release is available for download at: http://jackrabbit.apache.org/downloads.html See the full release notes below for details about this release. Release Notes -- Apache Jackrabbit -- Version 1.5.7 Introduction Apache Jackrabbit is a fully conforming implementation of the Content Repository for Java Technology API (JCR). A content repository is a hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation, and more. See the Jackrabbit web site at http://jackrabbit.apache.org/ for more information. Apache Jackrabbit 1.5.7 is a bug fix release that fixes issues reported against previous releases. This release is fully compatible with the earlier 1.5.x releases. See below for a full listing of fixes included in this release. Changes in this release --- All the fixes in this release are listed below per affected component. The modified components have had their version numbers upgraded to 1.5.7; other components are still at their previous 1.5.x versions. jackrabbit-core Bug fixes [JCR-2082] Query does not work after logging into workspace with no indexes [JCR-2129] Prevent data inconsistencies due to incorrect or missed ... [JCR-2138] Prevent persistence of faulty back-references [JCR-2168] Avoid premature publication of XAItemStateManager [JCR-2169] BundleDbPersistenceManager consistencyFix doesn't fix missing ... Improvements [JCR-2106] SystemSessions created for GarbageCollector are not logged out of jackrabbit-jcr2spi Improvements [JCR-1797] SPI: RepositoryService.getItemInfos should be allowed to ... You can look up individual issues for more details in the Jackrabbit issue tracker at https://issues.apache.org/jira/browse/JCR. Contributors The following people have contributed to this release by submitting bug reports or by participating in the issue resolution process. Angela Schreiber Martijn Hendriks Peter Dettman Jukka Zitting Mateusz Juszkiewicz Thomas Mueller Marcel Reutegger Michael Dürig Thank you to everyone involved! Release Contents This release consists of a single source archive (jackrabbit-1.5.7-src.jar) that contains all the Apache Jackrabbit components. Use the following commands (or the equivalent in your system) to build the release with Maven 2 and Java 1.4 or higher: jar xf jackrabbit-1.5.7-src.jar cd jackrabbit-1.5.7 mvn install Note that the OCM components require Java 5 or higher, and are not included in the build when using Java 1.4. The source archive is accompanied by SHA1 and MD5 checksums and a PGP signature that you can use to verify the authenticity of your download. The public key used for the PGP signature can be found at https://svn.apache.org/repos/asf/jackrabbit/dist/KEYS. The build will result in the following components (with artifactIds in parenthesis) being built and installed in your local Maven repository. Pre-built binary artifacts of these components are also available on the on the central Maven repository. * Jackrabbit Parent POM (jackrabbit-parent) The Maven parent POM for all Jackrabbit components. * Jackrabbit API (jackrabbit-api) Interface extensions that Apache Jackrabbit supports in addition to the standard JCR API. * Jackrabbit JCR Commons (jackrabbit-jcr-commons) General-purpose classes for use with the JCR API. * Jackrabbit JCR Tests (jackrabbit-jcr-tests) Set of JCR API test cases designed for testing the compliance of an implementation. Note that this is not the official JCR TCK! * Jackrabbit JCR Benchmarks (jackrabbit-jcr-benchmark) Framework for JCR performance tests. * Jackrabbit Core (jackrabbit-core) Core of the Apache Jackrabbit content repository implementation. * Jackrabbit Text Extractors (jackrabbit-text-extractors) Text extractor classes that allow Jackrabbit to extract text content from binary properties for full text indexing. * Jackrabbit JCR-RMI (jackrabbit-jcr-rmi) RMI remoting layer for the JCR API. * Jackrabbit WebDAV Library (jackrabbit-webdav) Interfaces and common utility classes used for building a WebDAV server or client. * Jackrabbit JCR Server (jackrabbit-jcr-server) WebDAV servlet implementations based on JCR. * Jackrabbit JCR Servlets (jackrabbit-jcr-servlet) Set of servlets and other classes designed to make it easier to use Jackrabbit and other JCR content repositories in web applications. * Jackrabbit Repository Classloader (jackrabbit-classloader) Java classloader for loading classes from JCR content repositories. * Jackrabbit Web Application (jackrabbit-webapp) Deployable Jackrabbit installation with WebDAV support for JCR. * Jackrabbit JCA Resource Adapter
[jira] Updated: (JCR-1972) Preserving UUID and document version history on repository migration
[ https://issues.apache.org/jira/browse/JCR-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paco Avila updated JCR-1972: Attachment: CheckinCalendarTest.java The missing test class Preserving UUID and document version history on repository migration Key: JCR-1972 URL: https://issues.apache.org/jira/browse/JCR-1972 Project: Jackrabbit Content Repository Issue Type: Wish Components: jackrabbit-core Affects Versions: core 1.4.8 Reporter: Paco Avila Assignee: Jukka Zitting Fix For: 1.6.0 Attachments: CheckinCalendarTest.java, Jackrabbit_modifications.pdf, JCR-1972.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch, JCR-1972_1.x.patch I have been working I an migration utility for OpenKM and I performed some changes in jackrabit-core to enable version import, preserving the modification date. Also modified org.apache.jackrabbit.core.NodeImpl to preserve UUID in the migration process. This migration process is needed because there are changes in repository node definition, and Jackrabbit can't deal with this actually. I've attache a PDF with the changes needed in Jackrabbit-core. It works and there was no problems with the migrated repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
