hi david
jira is down again :(
here some thoughts, that i would have put into the issue....
//---------------------------------------------------------------------
so, you are having:
jcr2spi -> your spi impl -> spi2jcr -> jackrabbit.
is that correct?
in that case i would like you to check, whether it makes a difference if
you omit 'your spi impl'. and if it indeed would make
a difference i suggest, that you provide some analysis on this.
it's perfectly possible, that the jcr2spi does not behave properly, but
i don't like guessing.
and maybe its the SPI that unintentionally leaves room for
interpretation (or jcr2spi is expecting the wrong thing)....
//---------------------------------------------------------------------
kind regards
angela
David Rauschenbach (JIRA) wrote:
[ https://issues.apache.org/jira/browse/JCR-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524114 ]
David Rauschenbach commented on JCR-1099:
-----------------------------------------
Thanks Angela,
Here's what I mean by my spi2jcr setup (repository.xml already attached):
// Bring up the in-mem repository
final URL REPOSITORY_URL =
getClass().getClassLoader().getResource("/repository.xml");
storageDir = new File(System.getProperty("java.io.tmpdir"));
RepositoryConfig config = RepositoryConfig.create(REPOSITORY_URL.toURI(),
storageDir.getAbsolutePath());
repository = new TransientRepository(config);
// Bring up the spi2jcr bridge in front of in-memory repository
BatchReadConfig batchReadConfig = new BatchReadConfig();
RepositoryService spi2jcrRepositoryService = new
RepositoryServiceImpl(repository, batchReadConfig);
Next, I wrote an SPI that is coupled to that spi2jcrRepositoryService. I wrap
my SPI in jcr2spi, so that's what I meant by the direct coupling of a JCR
front-end being invoked by unit tests, a jcr back-end that's the in-mem store,
and an SPI coupling inbetween.
jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
----------------------------------------------------------------------------
Key: JCR-1099
URL: https://issues.apache.org/jira/browse/JCR-1099
Project: Jackrabbit
Issue Type: Bug
Components: SPI
Reporter: David Rauschenbach
Assignee: angela
Attachments: repository.xml
The jcr2spi NodeEntryImpl class contains logic that causes getIndex() to call
itself.
Calling code:
Session sess = repo.login(creds);
Node inboxNode = sess.getRootNode().getNode("Inbox");
inboxNode.getPath(); <== blows stack
Tracing reveals:
1. NodeEntryImpl.getPath() ultimately calls getIndex()
2. getIndex() calls NodeState.getDefinition()
3. which calls ItemDefinitionProviderImpl.getQNodeDefinition(...)
4. which catches a RepositoryException then calls
NodeEntryImpl.getWorkspaceId()
5. which calls NodeEntryImpl.getWorkspaceIndex()
6. which calls getIndex() (back to step 2, ad infinitum)
Configuration:
1. A configuration is loaded specifying in-memory persist manager
2. Config is wrapped in TransientRepository
3. that's wrapped in spi2jcr's RepositoryService using default
BatchReadConfig
4. a jcr2spi provider is instantiated that directly couples to spi2jcr
5. Node in question is created as follows:
Session sess = repo.login(creds);
sess.getRootNode().addNode("Inbox", "nt:folder");
sess.save();
I guess that's about it.
David
