[jira] Commented: (JCR-1847) Path methods should throw a specific exception instead of RepositoryEx

[ https://issues.apache.org/jira/browse/JCR-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674559#action_12674559 ] Stefan Guggisberg commented on JCR-1847: the base exception was used solely inside

[jira] Commented: (JCR-1605) RepositoryLock does not work on NFS sometimes

[ https://issues.apache.org/jira/browse/JCR-1605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674593#action_12674593 ] Thomas Mueller commented on JCR-1605: - Committed in revision 745500 (repository-1.6.dtd

[jira] Created: (JCR-1985) NullPointerException GarbageCollector.scan()

NullPointerException GarbageCollector.scan() Key: JCR-1985 URL: https://issues.apache.org/jira/browse/JCR-1985 Project: Jackrabbit Content Repository Issue Type: Bug Components:

Re: Clustering w/ distributed cache

On Mon, Feb 16, 2009 at 9:02 PM, defeng defeng...@gmail.com wrote: I am using Jackrabbit 1.4.4 clustering. DB for persistent manager, and NFS for datastore. Everything works well, but since the Jackrabbit uses a Cluster-wide lock, many times, other JCR clients need to wait for a long time to

[jira] Commented: (JCR-1985) NullPointerException GarbageCollector.scan()

[ https://issues.apache.org/jira/browse/JCR-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674627#action_12674627 ] Jacco van Weert commented on JCR-1985: -- Hello Thomas, I looked to the repository.xml.

Re: Clustering w/ distributed cache

Hi, You are right, we have to serialize/deserialize objects. But that's the price we have to pay for the clustering, is it? The problem is not only serialization, you also have to send the objects over TCP/IP (if I understand you idea correctly). Each operation (including Node.getProperty,

[jira] Commented: (JCR-1985) NullPointerException GarbageCollector.scan()

[ https://issues.apache.org/jira/browse/JCR-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674635#action_12674635 ] Thomas Mueller commented on JCR-1985: - programmatic way to detect Yes. If this is null

[jira] Updated: (JCR-1985) NullPointerException in GarbageCollector.scan() if no DataStore configured

[ https://issues.apache.org/jira/browse/JCR-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1985: Summary: NullPointerException in GarbageCollector.scan() if no DataStore configured (was:

[jira] Created: (JCR-1986) XPathQueryBuilder treats ordering relations in property constraints as symmetrical

XPathQueryBuilder treats ordering relations in property constraints as symmetrical -- Key: JCR-1986 URL: https://issues.apache.org/jira/browse/JCR-1986 Project:

[jira] Created: (JCR-1987) Jackrabbit's lucene based query implementation does not check property constraints on the root node.

Jackrabbit's lucene based query implementation does not check property constraints on the root node. Key: JCR-1987 URL:

[jira] Commented: (JCR-1985) NullPointerException in GarbageCollector.scan() if no DataStore configured

[ https://issues.apache.org/jira/browse/JCR-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674644#action_12674644 ] Jacco van Weert commented on JCR-1985: -- Anyway the exception you get is not very

[jira] Resolved: (JCR-1985) NullPointerException in GarbageCollector.scan() if no DataStore configured

[ https://issues.apache.org/jira/browse/JCR-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller resolved JCR-1985. - Resolution: Fixed Fix Version/s: (was: 1.5.3) 1.6.0 Committed in

[jira] Updated: (JCR-1985) NullPointerException in GarbageCollector.scan() if no DataStore configured

[ https://issues.apache.org/jira/browse/JCR-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated JCR-1985: Priority: Minor (was: Major) NullPointerException in GarbageCollector.scan() if no DataStore

[jira] Commented: (JCR-1985) NullPointerException in GarbageCollector.scan() if no DataStore configured

[ https://issues.apache.org/jira/browse/JCR-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674657#action_12674657 ] Thomas Mueller commented on JCR-1985: - I saw that one of the tests first calls

Hudson build became unstable: Jack rabbit-trunk » Jackrabbit Core #366

See http://hudson.zones.apache.org/hudson/job/Jackrabbit-trunk/org.apache.jackrabbit$jackrabbit-core/366/changes

Re: Hudson build became unstable: Jackrabbit-trunk » Jackrabbit Core #366

Hi, The failure was: junit.framework.AssertionFailedError: expected:1 but was:0 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at

[jira] Commented: (JCR-1975) Connection timed out IO Exceptions

[ https://issues.apache.org/jira/browse/JCR-1975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674668#action_12674668 ] Edgar Vonk commented on JCR-1975: - Thanks Jukka. Is the automatic reconnect done by

[jira] Updated: (JCR-1949) NullPointerException on DelegatingObservationDispatcher cause by parameter null on call : createEventStateCollection(null)

[ https://issues.apache.org/jira/browse/JCR-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated JCR-1949: -- Attachment: JCR-1949.patch The patch seems incomplete. Here's my try at it.

Re: Making Derby an optional dependency

On Mon, Feb 16, 2009 at 18:51, Jukka Zitting jukka.zitt...@gmail.com wrote: I'd like to remove the compile-scope Derby dependency from jackrabbit-core. The runnable standalone server jar would still bundle Derby to keep things as simple as possible, but for other deployments you'd need to

Replace cluster-wide lock to itemstate-wide lock

Currently when I update an itemstate, I need to acquire a cluster lock (Journal.doLock()). This lock will block any update on others itemstates. I want to only lock *one* itemstate in the cluster. So I want to modify the SharedISM.update( ). (I donot use XA). Is there any side-effect?