[
https://issues.apache.org/jira/browse/JCR-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533166
]
angela commented on JCR-1099:
-----------------------------
i see 2 possibilities to solve this (apart from the obvious one "get rid of
SNSs" ;-)):
1) only check for NodeDefinition.allowsSNS if the definition has been retrieved
before.
if the definition is not yet present (which is the default for existing
nodes), the index is calculated from the
parents child entries.
potential drawback: more traffic to the server since the entries list
probably more often get invalidated compared
to the chance, that no matching definition is found in the
ItemDefinitionProvider (which would result in the
described problem).
2) omit the fallback in ItemDefinitionProvider, that tries to retrieve the
definition from the server
if no matching definition can be found.
drawback: if the definition is not available on the client, the retrieval
of the definition fails with exception. i couldn't
produce that since in my test case all definitions are available, but i'm
quite sure that this would cause problems.
so... basically i would prefer 2) but i think 1) is the proper solution to go
for just for the sake of stability and that
special (unlikely?) case that no matching definition can be found....
comments?
angela
> 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
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
