[jira] Updated: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1812: --- Component/s: jackrabbit-core Priority: Trivial (was: Major) Affects Version/s: (was: core 1.4.2) Fix Version/s: 1.5.0 Looks good. Commit it soon and I'll get this included in 1.5. :-) WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering, jackrabbit-core Reporter: Felix Meschberger Priority: Trivial Fix For: 1.5.0 Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger reassigned JCR-1812: -- Assignee: Felix Meschberger WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering, jackrabbit-core Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Trivial Fix For: 1.5.0 Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1814) Update maven-eclipse-plugin to 1.4 source evel
Update maven-eclipse-plugin to 1.4 source evel -- Key: JCR-1814 URL: https://issues.apache.org/jira/browse/JCR-1814 Project: Jackrabbit Issue Type: Bug Reporter: Stephane Landelle Priority: Trivial org.apache.jackrabbit.core.data.FileDataRecord uses assertions. Please update maven-eclipse-plugin configuration so projects are not configured with 1.3 compilation: artifactIdmaven-eclipse-plugin/artifactId configuration source1.4/source target1.4/target downloadSourcestrue/downloadSources /configuration /plugin Sincerely, Stephane Landelle -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1612) Reintroduce NamespaceStorage and namespace-caching
[ https://issues.apache.org/jira/browse/JCR-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639782#action_12639782 ] angela commented on JCR-1612: - but unless someone has a good idea on how to implement part 2 I think we should just drop it. fine by me. we can still create an new enhancement issue if we have a brilliant idea. Reintroduce NamespaceStorage and namespace-caching -- Key: JCR-1612 URL: https://issues.apache.org/jira/browse/JCR-1612 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr2spi Reporter: angela Assignee: Jukka Zitting Fix For: 1.5.0 hi jukka i open this issue as a reminder of our recent discussion in basel: we decided that you will - reintroduce the NamespaceStorage you recently removed from jcr2spi - reintroduce a namespace cache in jcr2spi (but using a simple map instead of NamespaceCache object) in addition we agreed that we want to share the NamespaceRegistryImpl between jcr2spi and jackrabbit-core and you volenteered to provide a patch for that. thanks in advance angela -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1809) Jcr2Spi: Avoid extra round trip to the SPI upon Node.getNode and Session.getItem
[ https://issues.apache.org/jira/browse/JCR-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1809. - Resolution: Fixed Fix Version/s: 1.5.0 Jcr2Spi: Avoid extra round trip to the SPI upon Node.getNode and Session.getItem Key: JCR-1809 URL: https://issues.apache.org/jira/browse/JCR-1809 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr2spi Reporter: angela Assignee: angela Fix For: 1.5.0 Upon Session.getItem/itemExists and Node.getNode/hasNode JCR2SPI currently tries to load the Node from the persistent layer (SPI) if no corresponding entry exists in the hierarchy. Since with JCR-1638 a flag has been introduced indicating if the child node entries are complete. In this case, the extra round trip could be 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-1798) JCR2SPI: Avoid individual Item reloading upon Session/Item.refresh(true)
[ https://issues.apache.org/jira/browse/JCR-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1798. - Resolution: Fixed Fix Version/s: 1.5.0 Assignee: angela JCR2SPI: Avoid individual Item reloading upon Session/Item.refresh(true) Key: JCR-1798 URL: https://issues.apache.org/jira/browse/JCR-1798 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr2spi Reporter: angela Assignee: angela Fix For: 1.5.0 with CacheBehaviour.INVALIDATE Item.refresh(true) and Session.refresh(true) results in individual reloading of the existing entries in the hierarchy circumventing all batch read optimization. Apart from general optimization of the refresh itself, refresh(true) should rather mark existing items and force a reload upon next access (similar to the behaviour implemented with refresh(false)). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1815) Benchmark: Improve transparency of test results
Benchmark: Improve transparency of test results --- Key: JCR-1815 URL: https://issues.apache.org/jira/browse/JCR-1815 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr-benchmark Reporter: angela as discussed in JCR-1501. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1815) Benchmark: Improve transparency of test results
[ https://issues.apache.org/jira/browse/JCR-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela updated JCR-1815: Fix Version/s: 1.6.0 Benchmark: Improve transparency of test results --- Key: JCR-1815 URL: https://issues.apache.org/jira/browse/JCR-1815 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr-benchmark Reporter: angela Fix For: 1.6.0 as discussed in JCR-1501. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1815) Benchmark: Improve transparency of test results
[ https://issues.apache.org/jira/browse/JCR-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1815. - Resolution: Fixed Benchmark: Improve transparency of test results --- Key: JCR-1815 URL: https://issues.apache.org/jira/browse/JCR-1815 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr-benchmark Reporter: angela Fix For: 1.6.0 as discussed in JCR-1501. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1501) poor performance on big collections
[ https://issues.apache.org/jira/browse/JCR-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639879#action_12639879 ] angela commented on JCR-1501: - i created issue #JCR-1815 to address the problem arising if login/refresh/getNodes are combined to analyze the performance of big collections. poor performance on big collections --- Key: JCR-1501 URL: https://issues.apache.org/jira/browse/JCR-1501 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr2spi Reporter: Julian Reschke With JCR-1437, I have added tests for measuring performance, both using plain Jackrabbit and through JCR2SPI. There are three tests (inside BigCollectionTest), all creating a collection of 500 nt:file nodes. - testGetChildren just instantiates the nodes - testBrowseMinusJcrData simulates browsing (getting metadata), but does not read jcr:data - testBrowse simulates browsing (getting metadata), including obtaining the content length (jcr:data) The tests can be run using mvn -Dtest=JCRBenchmark test under both jackrabbit-core and jackrabbit-jcr2spi. The results that I see are: For plain Jackrabbit: testGetChildren: 0.20 ms per iteration testBrowseMinusJcrData: 1.15 ms per iteration testBrowse: 2.55 ms per iteration With JCR2SPI, I see: testGetChildren: 281 ms per iteration testBrowseMinusJcrData: 577 ms per iteration testBrowse: 643 ms per iteration So, at least for these tests, JCR2SPI is several orders of magnitude slower. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1813) Invalid journal records during XATransactions
[
https://issues.apache.org/jira/browse/JCR-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639880#action_12639880
]
Stephane Landelle commented on JCR-1813:
My bad, my patch writes null records instead of not writing them.
A better solution would consist in:
- adding the hasUpdates method to ChangeLog
- skipping begin and end in
org.apache.jackrabbit.core.state.SharedItemStateManager$Update if local has
no updates with somehing like:
if (!local.hasUpdates()) {
return;
}
Sincerely,
Stephane Landelle
2008/10/15 Stephane Landelle (JIRA) [EMAIL PROTECTED]
Invalid journal records during XATransactions
-
Key: JCR-1813
URL: https://issues.apache.org/jira/browse/JCR-1813
Project: Jackrabbit
Issue Type: Bug
Components: clustering
Reporter: Stephane Landelle
Priority: Critical
During the prepare phase of a XATransaction, XAItemStateManager.prepare calls
ShareItemStageManager.beginUpdate that, in case of a ClusterNode, calls
ClusterNode.updatePrepared that does a ChangeLogRecord.write().
This last method is located in ClusterRecord and systematically write the
begin and the end of the journal record.
As a consequence, useless corrupted records are written in the journal
everytime a transaction ends without jackrabbit update! This causes polution
of the journal, as other cluster nodes try to sync with the corrupted updates
and fail doing so as ClusterRecordDeserializer can't deserialize it (the
record identifier is empty).
ChangeLogRecord (and even other ClusterRecord implementations too) should
only write if there's effective updates.
I propose the following solution:
*) add the following method in Changelog so clients can know if there's
effective updates:
public boolean hasUpdates() {
return !(addedStates.isEmpty() modifiedStates.isEmpty()
deletedStates.isEmpty() modifiedRefs.isEmpty());
}
*) change ClusterRecord with:
public final void write() throws JournalException {
if (hasUpdates()) {
record.writeString(workspace);
doWrite();
record.writeChar(END_MARKER);
}
}
protected abstract boolean hasUpdates();
*) implement hasUpdates for every ClusterRecord implementation:
ChangeLogRecord:
protected boolean hasUpdates() {
return changes.hasUpdates() || !events.isEmpty();
}
LockRecord and NamespaceRecord:
protected boolean hasUpdates() {
return true;
}
NodeTypeRecord:
protected boolean hasUpdates() {
return !collection.isEmpty();
}
Best regards,
Stephane Landelle
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1501) poor performance on big collections
[ https://issues.apache.org/jira/browse/JCR-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] angela resolved JCR-1501. - Resolution: Incomplete i run the benchmark with various configuration settings and the changes made with issue JCR-1815: CacheBehavior.OBSERVATION vs CacheBehavior.INVALIDATION Batch-Reading files/folders vs disabling BatchRead SPI implementation sending null vs Iterator upon NodeInfo.getChildInfos - Refresh is expensive with CacheBehavior.INVALIDATION only - simply accessing Item without refresh/login is slower with CacheBehavior.OBSERVATION since i left the test that re-accessed the items without refresh/logout in order to get an idea of the caching in jcr2spi, but didn't play around with cache-size. the latter would be useful, since items get reloaded from the SPI if the itemstate/item is g-collected. regarding the poor performance of getting big collections: i dare saying that the original test didn't show that. in order to have better test data i'd suggest to add tests that create a lot of big collections and access them randomly to address the concerns expressed by julian. resolving incomplete. poor performance on big collections --- Key: JCR-1501 URL: https://issues.apache.org/jira/browse/JCR-1501 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr2spi Reporter: Julian Reschke With JCR-1437, I have added tests for measuring performance, both using plain Jackrabbit and through JCR2SPI. There are three tests (inside BigCollectionTest), all creating a collection of 500 nt:file nodes. - testGetChildren just instantiates the nodes - testBrowseMinusJcrData simulates browsing (getting metadata), but does not read jcr:data - testBrowse simulates browsing (getting metadata), including obtaining the content length (jcr:data) The tests can be run using mvn -Dtest=JCRBenchmark test under both jackrabbit-core and jackrabbit-jcr2spi. The results that I see are: For plain Jackrabbit: testGetChildren: 0.20 ms per iteration testBrowseMinusJcrData: 1.15 ms per iteration testBrowse: 2.55 ms per iteration With JCR2SPI, I see: testGetChildren: 281 ms per iteration testBrowseMinusJcrData: 577 ms per iteration testBrowse: 643 ms per iteration So, at least for these tests, JCR2SPI is several orders of magnitude slower. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1803) Node.restore() throws java.lang.ClassCastException
[
https://issues.apache.org/jira/browse/JCR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jukka Zitting updated JCR-1803:
---
Component/s: jackrabbit-core
Affects Version/s: (was: 1.5.0)
Node.restore() throws java.lang.ClassCastException
--
Key: JCR-1803
URL: https://issues.apache.org/jira/browse/JCR-1803
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core, versioning
Affects Versions: core 1.4.6
Reporter: Przemo Pakulski
Assignee: Jukka Zitting
Priority: Blocker
Fix For: 1.5.0
I'm trying to upgrade to 1.5 using existing 1.3.x repository. Restore of
versionable node throws ClassCastException.
Caused by: java.lang.ClassCastException: org.apache.jackrabbit.uuid.UUID
at
org.apache.jackrabbit.core.value.InternalValue.getString(InternalValue.java:436)
at
org.apache.jackrabbit.core.version.InternalFrozenNodeImpl.init(InternalFrozenNodeImpl.java:113)
at
org.apache.jackrabbit.core.version.AbstractVersionManager.createInternalVersionItem(AbstractVersionManager.java:576)
at
org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:258)
at
org.apache.jackrabbit.core.version.InternalVersionImpl.getFrozenNode(InternalVersionImpl.java:111)
at
org.apache.jackrabbit.core.version.VersionImpl.getFrozenNode(VersionImpl.java:120)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:4180)
at
org.apache.jackrabbit.core.NodeImpl.internalRestore(NodeImpl.java:4141)
at org.apache.jackrabbit.core.NodeImpl.restore(NodeImpl.java:3429)
It seems that bug has been introduced already in 1.4 as part of JCR-926
(InternalValue cleanup).
Index:
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
===
---
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
(revision 549117)
+++
C:/data/jackrabbit/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalFrozenNodeImpl.java
(working copy)
@@ -109,10 +109,10 @@
PropertyState prop = props[i];
if (prop.getName().equals(QName.JCR_FROZENUUID)) {
// special property
-frozenUUID =
UUID.fromString(node.getPropertyValue(QName.JCR_FROZENUUID).internalValue().toString());
+frozenUUID =
UUID.fromString(node.getPropertyValue(QName.JCR_FROZENUUID).getString());
Probably one of the assumptions made was wrong :
- The type of QName.JCR_FROZENUUID is STRING (Object.toString() was used
before).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated JCR-1812: --- Fix Version/s: (was: 1.6.0) WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering, jackrabbit-core Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Trivial Fix For: 1.5.0 Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1091) more lenient behavior of Node#addMixin if mixin is already present
[ https://issues.apache.org/jira/browse/JCR-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639773#action_12639773 ] Jukka Zitting commented on JCR-1091: I never got around to resolving the test failures. I'm not sure if they still occur with this patch. more lenient behavior of Node#addMixin if mixin is already present --- Key: JCR-1091 URL: https://issues.apache.org/jira/browse/JCR-1091 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, jackrabbit-jcr-tests, jackrabbit-jcr2spi, JCR 2.0, nodetype Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-1091.patch Change implementation of addMixin() so that it doesn't fail when the mixin is already present. See also: jackrabbit core change: http://svn.apache.org/viewvc?view=revrevision=570149 JSR-283 issue: https://jsr-283.dev.java.net/issues/show_bug.cgi?id=353 (this affects both the TCK and JCR2SPI, so I didn't specify a component) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1612) Reintroduce NamespaceStorage and namespace-caching
[ https://issues.apache.org/jira/browse/JCR-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639781#action_12639781 ] Jukka Zitting commented on JCR-1612: Yep, I'm still looking at having some resolution to this before 1.5. The more I look at this the more I think that the NamespaceStorage interface just doesn't make much sense for jackrabbit-core. I'll restore it and the cache in jcr2spi, but unless someone has a good idea on how to implement part 2 I think we should just drop it. Reintroduce NamespaceStorage and namespace-caching -- Key: JCR-1612 URL: https://issues.apache.org/jira/browse/JCR-1612 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr2spi Reporter: angela Assignee: Jukka Zitting Fix For: 1.5.0 hi jukka i open this issue as a reminder of our recent discussion in basel: we decided that you will - reintroduce the NamespaceStorage you recently removed from jcr2spi - reintroduce a namespace cache in jcr2spi (but using a simple map instead of NamespaceCache object) in addition we agreed that we want to share the NamespaceRegistryImpl between jcr2spi and jackrabbit-core and you volenteered to provide a patch for that. thanks in advance angela -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1612) Reintroduce NamespaceStorage and namespace-caching
[ https://issues.apache.org/jira/browse/JCR-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639774#action_12639774 ] angela commented on JCR-1612: - what is the status of this issue? shall we split it into separate issues: 1) reverting the changes, 2) further enhancement to impl. a shared nsp-registry? would it be possible to fix the main part (1) for 1.5.0 as it is scheduled? Reintroduce NamespaceStorage and namespace-caching -- Key: JCR-1612 URL: https://issues.apache.org/jira/browse/JCR-1612 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-jcr2spi Reporter: angela Assignee: Jukka Zitting Fix For: 1.5.0 hi jukka i open this issue as a reminder of our recent discussion in basel: we decided that you will - reintroduce the NamespaceStorage you recently removed from jcr2spi - reintroduce a namespace cache in jcr2spi (but using a simple map instead of NamespaceCache object) in addition we agreed that we want to share the NamespaceRegistryImpl between jcr2spi and jackrabbit-core and you volenteered to provide a patch for that. thanks in advance angela -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed JCR-1812. -- Resolution: Fixed Applied patch to 1.5 branch in Rev. 704863 and to trunk in Rev. 704864. WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering, jackrabbit-core Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Trivial Fix For: 1.5.0 Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-1812: --- Attachment: JCR-cluster-update-log.patch Proposed patch, which also includes making use of SLF4Js log call optimization for not concatenating strings if not needed. WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering Affects Versions: core 1.4.2 Reporter: Felix Meschberger Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1812) WorkspaceUpdateChannel.updateCommitted logs too much
[ https://issues.apache.org/jira/browse/JCR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated JCR-1812: --- Fix Version/s: 1.6.0 WorkspaceUpdateChannel.updateCommitted logs too much Key: JCR-1812 URL: https://issues.apache.org/jira/browse/JCR-1812 Project: Jackrabbit Issue Type: Improvement Components: clustering, jackrabbit-core Reporter: Felix Meschberger Assignee: Felix Meschberger Priority: Trivial Fix For: 1.5.0, 1.6.0 Attachments: JCR-cluster-update-log.patch On each cluster record update, an info message is logged. I think this is too much and logging should be reduced to the DEBUG level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1793) Namespace handling in AbstractSession should be synchronized
[ https://issues.apache.org/jira/browse/JCR-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved JCR-1793. Resolution: Fixed Fix Version/s: 1.5.0 Assignee: Jukka Zitting Resolved in revisions 704002 and 704005. Merged to the 1.5 branch. Namespace handling in AbstractSession should be synchronized Key: JCR-1793 URL: https://issues.apache.org/jira/browse/JCR-1793 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-jcr-commons Reporter: Jukka Zitting Assignee: Jukka Zitting Priority: Minor Fix For: 1.5.0 The AbstractSession base class in o.a.j.commons implicitly assume that the session is never accessed concurrently from more than one thread and thus doesn't synchronize access to the namespace map. This causes problems when the session *is* accessed concurrently. Instead of relying on client code we should enforce thread-safety by explicitly synchronizing potentially unsafe operations on the session instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1091) more lenient behavior of Node#addMixin if mixin is already present
[ https://issues.apache.org/jira/browse/JCR-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639772#action_12639772 ] angela commented on JCR-1091: - what is the status of this issue? can we close it? is there something left to be done? more lenient behavior of Node#addMixin if mixin is already present --- Key: JCR-1091 URL: https://issues.apache.org/jira/browse/JCR-1091 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core, jackrabbit-jcr-tests, jackrabbit-jcr2spi, JCR 2.0, nodetype Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-1091.patch Change implementation of addMixin() so that it doesn't fail when the mixin is already present. See also: jackrabbit core change: http://svn.apache.org/viewvc?view=revrevision=570149 JSR-283 issue: https://jsr-283.dev.java.net/issues/show_bug.cgi?id=353 (this affects both the TCK and JCR2SPI, so I didn't specify a component) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639948#action_12639948 ] Christophe Lombart commented on JCR-1784: - Done. Thanks for your contribution. Do you want to see the latest path in the branch 1.5 ? I'm not sure that is critical for the release 1.5. OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.5.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5.0 Attachments: JCR-1784.additional.bonigopalan, JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (JCR-1804) Added the functionality to Map and Manage Type Enum
[ https://issues.apache.org/jira/browse/JCR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart reassigned JCR-1804: --- Assignee: Christophe Lombart Added the functionality to Map and Manage Type Enum --- Key: JCR-1804 URL: https://issues.apache.org/jira/browse/JCR-1804 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.6.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.6.0 Attachments: JCR-1804.bonigopalan.patch OCM API does not come with a mapper that can map Type Enum. I have added this functionality. Attached patch has test cases that tests the feature for Simple fields and Collection fields (For both anotations and digester based implementations) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1804) Added the functionality to Map and Manage Type Enum
[ https://issues.apache.org/jira/browse/JCR-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1804. - Resolution: Fixed Done. Thanks for the patch. I have only applied on the head (1.6-SNAPSHOT). I think this is not critical for the release 1.5. What do you think about that ? Added the functionality to Map and Manage Type Enum --- Key: JCR-1804 URL: https://issues.apache.org/jira/browse/JCR-1804 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.6.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.6.0 Attachments: JCR-1804.bonigopalan.patch OCM API does not come with a mapper that can map Type Enum. I have added this functionality. Attached patch has test cases that tests the feature for Simple fields and Collection fields (For both anotations and digester based implementations) -- 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-1784) OCM:The UUID of the collection elements changes on update.
I had submitted two patches on this issue. The first one was incomplete as it was not applying the same UUID interpretation to same-name-siblings other than collection elements. I feel both the patches should be applied to the same versions to provide a consistent interpretation. I am not sure which was the cut off date that Jukka decided for 1.5 release. I feel the first patch file was applied to the 1.5-SNAPSHOT. -Original Message- From: Christophe Lombart (JIRA) [mailto:[EMAIL PROTECTED] Sent: 16 October 2008 01:47 To: dev@jackrabbit.apache.org Subject: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update. [ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.p lugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639948#a ction_12639948 ] Christophe Lombart commented on JCR-1784: - Done. Thanks for your contribution. Do you want to see the latest path in the branch 1.5 ? I'm not sure that is critical for the release 1.5. OCM:The UUID of the collection elements changes on update. -- Key: JCR-1784 URL: https://issues.apache.org/jira/browse/JCR-1784 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-ocm Affects Versions: 1.5.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Fix For: 1.5.0 Attachments: JCR-1784.additional.bonigopalan, JCR-1784.bonigopalan.patch Original Estimate: 3h Remaining Estimate: 3h On ocm.update transaction, the Current implementation of DefaultCollectionConverterImpl recreates the colleciton-element nodes if there is no id field specificaiton. This is completely valid for majority of the cases. But I came across a case where the colleciton element has a uuid field. In this case also what is happening with the current implementation is that it drops all the elements from the old collection-elements and recreates the new ones. The major flip side is that now I am left with brand new UUIDs. I think we should address the uniqueness characteristics specified through UUID also while mapping colleciton elements. I have a patch and a TestCase to verify the same. I have implemented it only for the digester. If people feel the approach is right I will work out an annotation based testcase as well. I do not think it is going to fail even with annotations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: [jira] Resolved: (JCR-1804) Added the functionality to Map and Manage Type Enum
Agree with you. This Only needs to be in the trunk. Thanks! -Original Message- From: Christophe Lombart (JIRA) [mailto:[EMAIL PROTECTED] Sent: 16 October 2008 02:11 To: dev@jackrabbit.apache.org Subject: [jira] Resolved: (JCR-1804) Added the functionality to Map and Manage Type Enum [ https://issues.apache.org/jira/browse/JCR-1804?page=com.atlassian.jira.p lugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1804. - Resolution: Fixed Done. Thanks for the patch. I have only applied on the head (1.6-SNAPSHOT). I think this is not critical for the release 1.5. What do you think about that ? Added the functionality to Map and Manage Type Enum --- Key: JCR-1804 URL: https://issues.apache.org/jira/browse/JCR-1804 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.6.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.6.0 Attachments: JCR-1804.bonigopalan.patch OCM API does not come with a mapper that can map Type Enum. I have added this functionality. Attached patch has test cases that tests the feature for Simple fields and Collection fields (For both anotations and digester based implementations) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1816) Provide more options for OCM CRUD API Writers to enhance the functionality
Provide more options for OCM CRUD API Writers to enhance the functionality -- Key: JCR-1816 URL: https://issues.apache.org/jira/browse/JCR-1816 Project: Jackrabbit Issue Type: Improvement Reporter: Boni Gopalan Priority: Trivial Fix For: 1.6.0 I am working on an Extension to Object Content Manager and from that angle require a few methods and variable from the base classes to be exposed with protected access. I have modifier only the getters and these should not cause any issues to the current functionality. Request a review and addition to the trunk. 1. added a clone implementation to FilterImpl 2. Exposed : public CollectionConverter getCollectionConverter(Session session, CollectionDescriptor collectionDescriptor) from ObjectConverter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1816) Provide more options for OCM CRUD API Writers to enhance the functionality
[ https://issues.apache.org/jira/browse/JCR-1816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Boni Gopalan updated JCR-1816: -- Attachment: JCR-1816.bonigopalan.patch Provide more options for OCM CRUD API Writers to enhance the functionality -- Key: JCR-1816 URL: https://issues.apache.org/jira/browse/JCR-1816 Project: Jackrabbit Issue Type: Improvement Reporter: Boni Gopalan Priority: Trivial Fix For: 1.6.0 Attachments: JCR-1816.bonigopalan.patch I am working on an Extension to Object Content Manager and from that angle require a few methods and variable from the base classes to be exposed with protected access. I have modifier only the getters and these should not cause any issues to the current functionality. Request a review and addition to the trunk. 1. added a clone implementation to FilterImpl 2. Exposed : public CollectionConverter getCollectionConverter(Session session, CollectionDescriptor collectionDescriptor) from ObjectConverter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
