Hi,
We are trying to run the TCK tests in the jackrabbit-tests project, but
getting failures mostly related to missing nodetypes "test:versionable" and
"test:refTargetNode". Are the tests expecting these nodetypes to already
exist in your repository? If so, is there a cnd file that contains th
[
https://issues.apache.org/jira/browse/JCR-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Roberts updated JCR-799:
-
Attachment: repository.xml
this repository config demonstrates the bug.
> AbstractJournal doesn't create de
AbstractJournal doesn't create deep paths for revision files
Key: JCR-799
URL: https://issues.apache.org/jira/browse/JCR-799
Project: Jackrabbit
Issue Type: Bug
Component
[
https://issues.apache.org/jira/browse/JCR-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Roberts updated JCR-799:
-
Description: AbstractJournal throws when trying to create the revision file
if the directory the revision fi
Anything look strange in the stack traces from my last post on this thread?
Or does this all look 'normal'
-Dave
On 3/14/07, David Johnson <[EMAIL PROTECTED]> wrote:
I have 5-7 stack dumps from 2 different runs that I captured using jstack.
Here is an interesting (in that there are 2 blocked
[
https://issues.apache.org/jira/browse/JCR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-792.
---
Resolution: Fixed
the issue has been fixed as a side-effect of fixing JCR-689.
> after enabling
[
https://issues.apache.org/jira/browse/JCR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned JCR-792:
-
Assignee: Stefan Guggisberg
> after enabling access manager, I can't createNode and setPrope
[
https://issues.apache.org/jira/browse/JCR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reopened JCR-792:
---
reopening as i am now able to reproduce the issue
> after enabling access manager, I can't createNo
[
https://issues.apache.org/jira/browse/JCR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-792.
---
Resolution: Invalid
i ran your test code (against svn trunk). here's the console output:
freshD
[
https://issues.apache.org/jira/browse/JCR-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-798.
---
Resolution: Fixed
Fix Version/s: 1.3
fixed in svn r519892.
since i haven't been able to
[
https://issues.apache.org/jira/browse/JCR-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned JCR-798:
-
Assignee: Stefan Guggisberg
> ConcurrentModificationException during logout
> --
ConcurrentModificationException during logout
-
Key: JCR-798
URL: https://issues.apache.org/jira/browse/JCR-798
Project: Jackrabbit
Issue Type: Bug
Components: core
Environment:
[
https://issues.apache.org/jira/browse/JCR-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated JCR-791:
-
Attachment: PerformanceTest.java
Performance test case for queries with 'not null' condition.
> Imp
[
https://issues.apache.org/jira/browse/JCR-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated JCR-791:
-
Attachment: MatchAllScorer.java.diff
MatchAllScorer diff, which introduces a BitSet cache.
> Improv
Hi Martijn,
Martijn Hendriks wrote:
The second scenario that I sketched in my previous message is
possible: I now can reproduce that values of an ItemStateReferenceMap
are evicted by garbage collection during the iteration over that map
in the LocalItemStateManager.dispose method (with Jackrabbi
Hi Christoph,
Christoph Kiehl wrote:
The effect of caching should increase if you use queries which test an
attribute more than once, like:
//element(*, nt:unstructured)[EMAIL PROTECTED]'1' or @foo!='2' or @foo!='3']
May be we can add a configuration option to SearchIndex which allows to
ena
Christoph Kiehl wrote:
Marcel Reutegger wrote:
Wouldn't it make sense to rewrite all @foo:bar!='john' queries to
not(@foo:bar!='john') by default instead of using creating a
MatchAllQuery?
do you mean rewrite: @foo:bar!='john' to not(@foo:bar='john') ?
Yes, of course. My mistake. Do you th
17 matches
Mail list logo
