[jira] Assigned: (JCR-997) ValueFactory is not extensible
[ https://issues.apache.org/jira/browse/JCR-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger reassigned JCR-997: Assignee: Marcel Reutegger ValueFactory is not extensible -- Key: JCR-997 URL: https://issues.apache.org/jira/browse/JCR-997 Project: Jackrabbit Issue Type: Improvement Components: core Reporter: Jukka Zitting Assignee: Marcel Reutegger Priority: Minor The Jackrabbit ValueFactory implementation should have a generic base class in jackrabbit-jcr-commons. This base class could be reused in SPI. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1003) Use inheritance rather than delegation for SPI ValueFactoryImpl
Use inheritance rather than delegation for SPI ValueFactoryImpl --- Key: JCR-1003 URL: https://issues.apache.org/jira/browse/JCR-1003 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: Marcel Reutegger Priority: Minor The ValueFactoryImpl now has a protected constructor and the SPI variant of the it can use it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1003) Use inheritance rather than delegation for SPI ValueFactoryImpl
[ https://issues.apache.org/jira/browse/JCR-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1003. --- Resolution: Fixed Fix Version/s: 1.4 Fixed in revision: 553407 Use inheritance rather than delegation for SPI ValueFactoryImpl --- Key: JCR-1003 URL: https://issues.apache.org/jira/browse/JCR-1003 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: Marcel Reutegger Priority: Minor Fix For: 1.4 The ValueFactoryImpl now has a protected constructor and the SPI variant of the it can use it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1003) Use inheritance rather than delegation for SPI ValueFactoryImpl
[ https://issues.apache.org/jira/browse/JCR-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-1003: -- Description: The ValueFactoryImpl now has a protected constructor and the SPI variant of the value factory can use it. (was: The ValueFactoryImpl now has a protected constructor and the SPI variant of the it can use it.) Use inheritance rather than delegation for SPI ValueFactoryImpl --- Key: JCR-1003 URL: https://issues.apache.org/jira/browse/JCR-1003 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: Marcel Reutegger Priority: Minor Fix For: 1.4 The ValueFactoryImpl now has a protected constructor and the SPI variant of the value factory can use it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1001) SPI: prefer 'Iterator' instead of specialized subclasses
[ https://issues.apache.org/jira/browse/JCR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1001. - Resolution: Fixed removed: IdIterator, EventIterator, QNodeTypeDefinitionIterator, QResultRowIterator interfaces and implementing classes. All corresponding return values were changed to 'Iterator' except for QResultRowIterator which was changed to 'RangeIterator' due to usage of the additional methods within the query code. rev. 553409 SPI: prefer 'Iterator' instead of specialized subclasses Key: JCR-1001 URL: https://issues.apache.org/jira/browse/JCR-1001 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: angela Assignee: angela Priority: Minor in the F2F we agreed that the SPI should rather use 'Iterator' instead of specialized subclassed (or RangeIterator). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-999) SPI: provide batch read functionality
[ https://issues.apache.org/jira/browse/JCR-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-999. Resolution: Fixed SPI: provide batch read functionality - Key: JCR-999 URL: https://issues.apache.org/jira/browse/JCR-999 Project: Jackrabbit Issue Type: New Feature Components: SPI Reporter: angela Assignee: angela extend RepositoryService interface to allow for BatchRead and modify jcr2spi accordingly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1004) SPI: Add RepositoryService.getQNodeTypeDefinition
SPI: Add RepositoryService.getQNodeTypeDefinition - Key: JCR-1004 URL: https://issues.apache.org/jira/browse/JCR-1004 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: angela Assignee: angela Finding of the F2F (2/3 July) similar to recent modifications to the retrieval of name spaces the node type management should be changed in order to only retrieve the complete set of node types on demand. Otherwise single node type definitions should be retrieved as required. To achieve this we agreed to add RepositoryService.getQNodeTypeDefinition -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1001) SPI: prefer 'Iterator' instead of specialized subclasses
[ https://issues.apache.org/jira/browse/JCR-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510310 ] angela commented on JCR-1001: - slightly modified contrib/jackrabbit-spi-xml in order not to break its compilation (untested). rev. 553411 SPI: prefer 'Iterator' instead of specialized subclasses Key: JCR-1001 URL: https://issues.apache.org/jira/browse/JCR-1001 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: angela Assignee: angela Priority: Minor in the F2F we agreed that the SPI should rather use 'Iterator' instead of specialized subclassed (or RangeIterator). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1005) More Fine grained Permission Flags
More Fine grained Permission Flags -- Key: JCR-1005 URL: https://issues.apache.org/jira/browse/JCR-1005 Project: Jackrabbit Issue Type: Improvement Components: security Affects Versions: 1.3 Reporter: Claus Köll It would be fine to have one more Permission Flag on node add. At the moment there are 3 flags. We need to know if a node will be updated or created. This is not possible with the current implementation because on node add the permission flag AccessManager.WRITE will be used. This is a Problem in a WebDav Scenario with Microsoft-Word because if i open a Node and try to save it i need write permissions on the parent node. this is ok. If a user trys to save the file with a other name he can because the same PermissionFlag will be used. Maybe there is a other solution for this problem ? BR, claus -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SPI Contribution: Status
Hi, On 7/4/07, Thomas Mueller [EMAIL PROTECTED] wrote: - a impl. logging SPI calls would be very convenient The JCRLog could be extended to support that, see: http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/jcrlog There's also an interesting generic tool currently entering the Apache Incubator, see http://wiki.apache.org/incubator/JrsProposal. BR, Jukka Zitting
[jira] Updated: (JCR-1006) StackOverflowError if too many versions of a node are created
[ https://issues.apache.org/jira/browse/JCR-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christoph Kiehl updated JCR-1006: - Attachment: VersionIteratorImpl.patch This patch collects all version ids iteratively instead of recursively to avoid StackOverflowErrors. StackOverflowError if too many versions of a node are created - Key: JCR-1006 URL: https://issues.apache.org/jira/browse/JCR-1006 Project: Jackrabbit Issue Type: Bug Components: versioning Affects Versions: 1.3 Reporter: Christoph Kiehl Attachments: VersionIteratorImpl.patch In org.apache.jackrabbit.core.version.VersionIteratorImpl addVersion() is called recursively which can cause StackOverflowErrors if there are too many versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1007) Move common implementations of SPI interfaces to spi-commons module
Move common implementations of SPI interfaces to spi-commons module --- Key: JCR-1007 URL: https://issues.apache.org/jira/browse/JCR-1007 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: Marcel Reutegger Priority: Minor Some of the spi modules use nearly duplicate code, which should be moved to the spi-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1007) Move common implementations of SPI interfaces to spi-commons module
[ https://issues.apache.org/jira/browse/JCR-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1007. --- Resolution: Fixed Done in revision: 553507 Move common implementations of SPI interfaces to spi-commons module --- Key: JCR-1007 URL: https://issues.apache.org/jira/browse/JCR-1007 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: Marcel Reutegger Priority: Minor Some of the spi modules use nearly duplicate code, which should be moved to the spi-commons module. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-812) TCK: RestoreTest.testRestoreLabel
[ https://issues.apache.org/jira/browse/JCR-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-812. -- Resolution: Fixed Fix Version/s: 1.4 Changed the test to only focus on a single versionable node. Fixed in revision: 553510 TCK: RestoreTest.testRestoreLabel - Key: JCR-812 URL: https://issues.apache.org/jira/browse/JCR-812 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: angela Fix For: 1.4 According to tobi the jackrabbit implementation of 'Node.restoreByLabel' is an interpretation of the specification regarding the restore behaviour of versionable child nodes. while that interpetration might be legal unless the specification is violated, i would argue that the TCK should not test the interpretation. therefore i suggest to modify org.apache.jackrabbit.test.api.version.RestoreTest.testRestoreLabel by skipping line 334 - 345 in order to limit the test case to the behaviour that is defined by the specification. regards angela ps: the mentioned test is also executed within the scope of WorkspaceRestoreTest because the latter extends RestoreTest that's misleading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Question
I spent about 2 hours looking for the appropriate forum to post this question. This one is the best I came up with. Please forgive me, but my question is not Jackrabbit specific. What I want to do is be able to refer from one node via a property to another node in a different workspace. For example: WorkspaceA root node Node 001 Property:REFERENCEABLE, value=??? can I refer to Node 00X, UUID 0123?? WorkspaceB root node Node 00X UUID = 0123 Is this possible in Jackrabbit? Is this possible in other implementations of the JSR-170? Is this something that is not defined by the JSR-170? I have read thru the Spec, and it does not seem to address this, so I am assuming that the JSR-170 does not address this. It talks about corresponding nodes (which I am not sure I understand yet), but this does not seem to address the question I am interested in. Thanks. mjkelleher [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Question-tf4029888.html#a11446925 Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
[jira] Commented: (JCR-774) TCK: Test that expect that modifications made by Session1 are automatically visible to Session2
[ https://issues.apache.org/jira/browse/JCR-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510371 ] Marcel Reutegger commented on JCR-774: -- Added the missing Node.refresh() call in NodeCanAddMixinTest.testLocked. Fixed in revision: 553515 TCK: Test that expect that modifications made by Session1 are automatically visible to Session2 --- Key: JCR-774 URL: https://issues.apache.org/jira/browse/JCR-774 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: angela Priority: Minor Attachments: NodeCanAddMixinTest.patch, NodeTest.patch While changes made by session1 are automatically visible to any other session2 with the RI, this is not required by the specification. Therefore i would suggest to modify the following test cases: - NodeUUIDTest.testSaveMovedRefNode() - SessionUUIDTest.testSaveMovedRefNode() - no patch. sorry. - NodeTest.testRemoveInvalidItemStateException() - see patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1008) SerializationTest leaks sessions
SerializationTest leaks sessions Key: JCR-1008 URL: https://issues.apache.org/jira/browse/JCR-1008 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: Marcel Reutegger Priority: Minor Fix For: 1.4 The class TreeComparator extends from AbstractJCRTest and opens a session in its constructor because it calls the setUp() method. The tearDown() method is never called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question
Hi, the JSR-170 spec explicitly states that references are within the same workspace only. generally, there are a number of issues with cross workspace references. to mention one, your session is tied to one workspace and the access to another workspace is not obvious without creating another session. also, since there can be multiple workspaces with the node with that given UUID it would not be trivial to identify the node just through the UUID. referential integrity is a whole different issue. In JSR-283 cross repository and cross workspace references are considered as a topic to resolve. In my experience I found that a lot of people that were interested in cross workspace references were not really looking for all the attributes of a JCR reference and either ended up putting all the data into one workspace (rightfully so, since the workspace metaphore is frequently abused as some grouping or even access control mechanism) or used for example UUID's as strings and resolved the reference in the application with a getByUUID() call on the target workspace. Maybe you can outline your usecase a little bit more in detail, I would be happy to see what suggestions I could come up with. regards, david .ps: I read the property in your example as a reference property, since there is no referenceable property. I assume that's correct, right? On 7/5/07, qcfireball [EMAIL PROTECTED] wrote: I spent about 2 hours looking for the appropriate forum to post this question. This one is the best I came up with. Please forgive me, but my question is not Jackrabbit specific. What I want to do is be able to refer from one node via a property to another node in a different workspace. For example: WorkspaceA root node Node 001 Property:REFERENCEABLE, value=??? can I refer to Node 00X, UUID 0123?? WorkspaceB root node Node 00X UUID = 0123 Is this possible in Jackrabbit? Is this possible in other implementations of the JSR-170? Is this something that is not defined by the JSR-170? I have read thru the Spec, and it does not seem to address this, so I am assuming that the JSR-170 does not address this. It talks about corresponding nodes (which I am not sure I understand yet), but this does not seem to address the question I am interested in. Thanks. mjkelleher [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Question-tf4029888.html#a11446925 Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
[jira] Resolved: (JCR-1008) SerializationTest leaks sessions
[ https://issues.apache.org/jira/browse/JCR-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1008. --- Resolution: Fixed Fixed in revision: 553529 SerializationTest leaks sessions Key: JCR-1008 URL: https://issues.apache.org/jira/browse/JCR-1008 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: Marcel Reutegger Priority: Minor Fix For: 1.4 The class TreeComparator extends from AbstractJCRTest and opens a session in its constructor because it calls the setUp() method. The tearDown() method is never called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Xpath property predicates
Frédéric Esnault wrote: I'm wondering if it is a bug in Jackrabbit or if it's just not possible with JSR 170 Xpath query (it works with real XPath). JSR 170 does only specify property comparison with a literal and not with another property. Please file a jira enhancement issue if you want jackrabbit to support this. regards marcel
[jira] Created: (JCR-1009) JCR2SPI: add JNDI support
JCR2SPI: add JNDI support - Key: JCR-1009 URL: https://issues.apache.org/jira/browse/JCR-1009 Project: Jackrabbit Issue Type: New Feature Components: SPI Reporter: angela Assignee: Julian Reschke Priority: Minor adding jndi support to jcr2spi was one of the improvements that came up during the f2f. julian volunteered to take a look at it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-774) TCK: Test that expect that modifications made by Session1 are automatically visible to Session2
[ https://issues.apache.org/jira/browse/JCR-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-774. -- Resolution: Fixed Fix Version/s: 1.4 No more changes needed. Setting to fixed. TCK: Test that expect that modifications made by Session1 are automatically visible to Session2 --- Key: JCR-774 URL: https://issues.apache.org/jira/browse/JCR-774 Project: Jackrabbit Issue Type: Bug Components: JCR TCK Reporter: angela Priority: Minor Fix For: 1.4 Attachments: NodeCanAddMixinTest.patch, NodeTest.patch While changes made by session1 are automatically visible to any other session2 with the RI, this is not required by the specification. Therefore i would suggest to modify the following test cases: - NodeUUIDTest.testSaveMovedRefNode() - SessionUUIDTest.testSaveMovedRefNode() - no patch. sorry. - NodeTest.testRemoveInvalidItemStateException() - see patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Question
David Nuescheler wrote: In my experience I found that a lot of people that were interested in cross workspace references were not really looking for all the attributes of a JCR reference and either ended up putting all the data into one workspace (rightfully so, since the workspace metaphore is frequently abused as some grouping or even access control mechanism) or used for example UUID's as strings and resolved the reference in the application with a getByUUID() call on the target workspace. Could you outline some valid use cases for using multiple workspaces? The only one I found was having two workspaces: one for published content and one for content. But this is just for our use case which is centered around CMS, editing, publishing. I'm sure there are much more situations were it is worth to consider using multiple workspaces. This might be helpful for newcomers as well to show what jackrabbit could be used for. Cheers, Christoph
[jira] Resolved: (JCR-1010) Test failures with spi2jcr in AddEventListenerTest
[ https://issues.apache.org/jira/browse/JCR-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved JCR-1010. --- Resolution: Fixed Fixed in revision: 553547 Test failures with spi2jcr in AddEventListenerTest -- Key: JCR-1010 URL: https://issues.apache.org/jira/browse/JCR-1010 Project: Jackrabbit Issue Type: Bug Components: SPI Reporter: Marcel Reutegger Priority: Minor Two tests fail: - AddEventListenerTest.testUUID - AddEventListenerTest.testNodeType -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1010) Test failures with spi2jcr in AddEventListenerTest
Test failures with spi2jcr in AddEventListenerTest -- Key: JCR-1010 URL: https://issues.apache.org/jira/browse/JCR-1010 Project: Jackrabbit Issue Type: Bug Components: SPI Reporter: Marcel Reutegger Priority: Minor Two tests fail: - AddEventListenerTest.testUUID - AddEventListenerTest.testNodeType -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1012) JCR2SPI: Optimization for Item.refresh and Session.refresh
JCR2SPI: Optimization for Item.refresh and Session.refresh -- Key: JCR-1012 URL: https://issues.apache.org/jira/browse/JCR-1012 Project: Jackrabbit Issue Type: Improvement Reporter: angela (suggested by david) Item.refresh and Session.refresh could be optimized if it was possible to find out, if there are external modifications affecting the tree to be refreshed and if the information would allow to specifically invalidate affected ItemStates. Currently all ItemStates present in the tree below the given Item are invalidated (and updated upon the next access). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: JSR-283 TCK?
Thanks, Roy and Bertrand, it's clear now. Note that you only need the TCK if you are implementing an independent implementation, or if you want to certify a forked version of Jackrabbit. The Apache Jackrabbit release builds are already tested against the TCK. We'll just stick to Jackrabbit without the fork :) Kind regards, Met vriendelijke groet, Arjé Cahn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 [EMAIL PROTECTED] / [EMAIL PROTECTED] -- Hippo http://www.hippo.nl Hippo CMS community http://www.hippocms.org My weblog http://blogs.hippo.nl/arje -- Upcoming presentation June 25th, New York: Open Source Content Management in the Enterprise http://www.soaeosconference.sys-con.com/general/session07.htm?id=30 --
[jira] Created: (JCR-1011) JCR2SPI: add configurable cache for Item instances (ItemManager)
JCR2SPI: add configurable cache for Item instances (ItemManager) Key: JCR-1011 URL: https://issues.apache.org/jira/browse/JCR-1011 Project: Jackrabbit Issue Type: Improvement Components: SPI Reporter: angela Currently the ItemManager implementation uses a simple map with weak keys (ItemState) and weak values (Item) as cache. Marcel recently suggested to replace this with a more sophisticated cache mechanism that can be configured. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1013) Connection.setAutoCommit(...) fails if connection is managed for JNDIDatabasePersistenceManager
[ https://issues.apache.org/jira/browse/JCR-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel May updated JCR-1013: - Attachment: patch.txt Patch for DatabasePersistenceManager and DatabaseFileSystem.java Connection.setAutoCommit(...) fails if connection is managed for JNDIDatabasePersistenceManager --- Key: JCR-1013 URL: https://issues.apache.org/jira/browse/JCR-1013 Project: Jackrabbit Issue Type: Bug Affects Versions: 1.3 Environment: JBoss, Jackrabbit 1.3, JNDIDatabasePersistenceManager Reporter: Marcel May Attachments: patch.txt Invoking setAutoCommit() on a db connection fails if the connection is managed. I propose as a workaround to check if the auto commit must be set previous to setting it (a trivial patch will be provided). This can happen eg. if you use JNDI (eg JNDIDatabasePersistenceManager) to fetch the connection on JBoss, and the persistent manager tries to reconnect (see stack trace below). 05 Jul 09:54:24 ERROR sePersistenceManager| failed to re-establish connection java.sql.SQLException: You cannot set autocommit during a managed transaction! at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.setJdbcAutoCommit(BaseWrapperManagedConnection.java:482) at org.jboss.resource.adapter.jdbc.WrappedConnection.setAutoCommit(WrappedConnection.java:322) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.initConnection(DatabasePersistenceManager.java:731) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.reestablishConnection(DatabasePersistenceManager.java:806) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.executeStmt(DatabasePersistenceManager.java:852) at org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.exists(DatabasePersistenceManager.java:647) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasNonVirtualItemState(SharedItemStateManager.java:1102) at org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(SharedItemStateManager.java:289) at org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(LocalItemStateManager.java:180) at org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemStateManager.java:252) at org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:174) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-926) Global data store for binaries
[ https://issues.apache.org/jira/browse/JCR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510515 ] Pablo Rios commented on JCR-926: Which is the revision the last version of the binary data store patch should be applied to ? (I would like to have both the old style BLOBStore and the new style DataStore implementations co-exist and the clean up of the InternalValue.internalValue() method) The simplest steps that I found to apply the dataStore3.patch was: - checkout revision 552445 (revision of the files modified by this patch) - delete org.apache.jackrabbit.core.data package (already exists in revision 552445) - make a copy of the file BLOBFileValue.java as BLOBValue.java (can't find the file to patch at line 2659) - apply dataStore3.patch With the data store feature disabled (org.jackrabbit.useDataStore=false) all TCK tests passed, but with this feature enabled (org.jackrabbit.useDataStore=true) I got 46 errors and 10 failures. I suppose these test failures are related with the steps above. I would like to start contributing testing this feature. Global data store for binaries -- Key: JCR-926 URL: https://issues.apache.org/jira/browse/JCR-926 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Jukka Zitting Attachments: dataStore.patch, DataStore.patch, DataStore2.patch, dataStore3.patch, internalValue.patch, ReadWhileSaveTest.patch There are three main problems with the way Jackrabbit currently handles large binary values: 1) Persisting a large binary value blocks access to the persistence layer for extended amounts of time (see JCR-314) 2) At least two copies of binary streams are made when saving them through the JCR API: one in the transient space, and one when persisting the value 3) Versioining and copy operations on nodes or subtrees that contain large binary values can quickly end up consuming excessive amounts of storage space. To solve these issues (and to get other nice benefits), I propose that we implement a global data store concept in the repository. A data store is an append-only set of binary values that uses short identifiers to identify and access the stored binary values. The data store would trivially fit the requirements of transient space and transaction handling due to the append-only nature. An explicit mark-and-sweep garbage collection process could be added to avoid concerns about storing garbage values. See the recent NGP value record discussion, especially [1], for more background on this idea. [1] http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200705.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-926) Global data store for binaries
[ https://issues.apache.org/jira/browse/JCR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510521 ] Pablo Rios commented on JCR-926: I have a couple of questions about the data store. Given the append-only nature of this feature, when a node with a binary property is removed binary content remains in the data store. When do you expect to have a garbage collection process of binary content (files) in the file system ? Are you planning to provide a database-backed implementation of the data store ? Regards, Pablo Global data store for binaries -- Key: JCR-926 URL: https://issues.apache.org/jira/browse/JCR-926 Project: Jackrabbit Issue Type: New Feature Components: core Reporter: Jukka Zitting Attachments: dataStore.patch, DataStore.patch, DataStore2.patch, dataStore3.patch, internalValue.patch, ReadWhileSaveTest.patch There are three main problems with the way Jackrabbit currently handles large binary values: 1) Persisting a large binary value blocks access to the persistence layer for extended amounts of time (see JCR-314) 2) At least two copies of binary streams are made when saving them through the JCR API: one in the transient space, and one when persisting the value 3) Versioining and copy operations on nodes or subtrees that contain large binary values can quickly end up consuming excessive amounts of storage space. To solve these issues (and to get other nice benefits), I propose that we implement a global data store concept in the repository. A data store is an append-only set of binary values that uses short identifiers to identify and access the stored binary values. The data store would trivially fit the requirements of transient space and transaction handling due to the append-only nature. An explicit mark-and-sweep garbage collection process could be added to avoid concerns about storing garbage values. See the recent NGP value record discussion, especially [1], for more background on this idea. [1] http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200705.mbox/[EMAIL PROTECTED] -- 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-926) Global data store for binaries
Hi, With the data store feature disabled all TCK tests passed, Same for me. with this feature enabled I got 46 errors and 10 failures. It worked for me. I suppose these test failures are related with the steps above. Probably. How run the tests? Which is the revision the last version of the binary data store patch should be applied to ? ... I didn't write that down. I will merge my changes today and create a new patch, where I will tell the revision I used. Given the append-only nature of this feature, when a node with a binary property is removed binary content remains in the data store. When do you expect to have a garbage collection process of binary content (files) in the file system ? I started to implement that yesterday. I have some ideas how to make it faster than simply 'scan through the whole repository, mark all blobs, delete unmarked'. However the first implementation will be about like that. Also, the garbage needs to be a background process (unlike memory garbage collection). The patch will contain more information about that. Are you planning to provide a database-backed implementation of the data store ? So far I didn't plan to implement that, but it should be trivial (the DataStore API is very simple). Thomas
