That ticket was the reason I used an in-memory Derby instead of
InMemPersistenceManager. Don't know if it has anything to do with
Alvaros initial problem.
/Pontus
On 2012-01-02T17:47:24 CET, Lukas Kahwe Smith wrote:
Hi,
is this ticket in anyway related to this?
https://issues.apache.org/jira/browse/JCR-3183
On Dec 1, 2011, at 21:16 , Pontus Amberg wrote:
I had Jackrabbit running in-memory for tests but instead of
InMemPersistenceManager I used DerbyPersistenceManager where Derby is running
in-memory.
I based my config on the one described in this thread
http://jackrabbit.510166.n4.nabble.com/In-memory-Repository-td522969.html where
I at least replaced the PersistenceManager with the DerbyPersistenceManager.
How to run Derby in-memory is described here
http://wiki.apache.org/db-derby/InMemoryBackEndPrimer .
/Pontus
On 2011-12-01T15:28:49 CET, Alvaro Videla wrote:
Hi,
When I try to use the
class org.apache.jackrabbit.core.persistence.mem.InMemPersistenceManager
for my test workspace I get the following error in the logs:
BeanConfig.java:185
org.apache.jackrabbit.core.persistence.mem.InMemPersistenceManager
What's the recommended way to use jackrabbit for testing purposes? I'm
trying to avoid doing file I/O for the tests.
Also in which unit is the *initialCapacity *parameter expressed
in the InMemPersistenceManager class?
Regards,
Alvaro
Lukas Kahwe Smith
[email protected]
