Hi, I think the first issue is the same as: https://issues.apache.org/jira/browse/JCR-1879
If you are using JR 1.5.x, you can add a new comment on the issue in order to backport the fix in the 1.5 branch. pkrishna a écrit : > We have been using JackRabbit for the last 6 months and have been able to > save and retrieve data. So far the configuration has been pointing to a > folder in the filesystem. I have recently switched over to point to a local > oracle database and modified the workspace and repository.xml accordingly. I > have run into 2 issues while testing our APIs against the content > repository. > > I am forced to remove both the lucene index folder and drop the tables from > the database every time I re-run the integration test. Otherwise, I get an > exception as below and not sure how I can get past this problem:(here is the > snippet of the exception) > > Failed to initialize workspace 'default' > javax.jcr.RepositoryException: Directory was previously created with a > different LockFactory instance; please pass null as the lockFactory instance > and use setLockFactory to change it: Directory was previously created with a > different LockFactory instance; please pass null as the lockFactory instance > and use setLockFactory to change it: Directory was previously created with a > different LockFactory instance; please pass null as the lockFactory instance > and use setLockFactory to change it > at > org.apache.jackrabbit.core.SearchManager.initializeQueryHandler(SearchManager.java:585) > at > org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:265) > at > org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1613) > at > org.apache.jackrabbit.core.RepositoryImpl.initWorkspace(RepositoryImpl.java:606) > > Incidentally, the RepositoryFactoryBean is injected through Spring. I am not > sure if this is an issue. > > The Other issue is once I have my integration test running after removing > the index folder and dropping the tables, I execute an Xpath query like this > below: > /abfaa8a2-950e-4aac-8865-07f5acee09b9/ecr:varia...@ecr:documentState != > 'deleted'] I always get no results back. > > I have a browse method which browses the repository and I can see the > nodePath exists in the repository. As I mentioned before, the same test case > works great with fileSystem repository. > > Can someone point out what I am missing that causing both these issues? > > thanks in advance. > > -- Sébastien Launay
