jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1099) jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
Date Mon, 08 Oct 2007 17:19:50 GMT

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


Mime
View raw message