Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <8752161.1191863990857.JavaMail.jira@brutus>
Date: Mon, 8 Oct 2007 10:19:50 -0700 (PDT)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1099) jcr2spi NodeEntryImpl.getPath() blows
 stack due to getIndex() calling itself
In-Reply-To: <7192725.1188421950618.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.