jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Rauschenbach (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1099) jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
Date Tue, 11 Sep 2007 00:14:30 GMT

    [ https://issues.apache.org/jira/browse/JCR-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526314
] 

David Rauschenbach commented on JCR-1099:
-----------------------------------------

I have identified and resolved the trigger of this problem. In my SPI, my NodeTypeDefinition
"propertyDefs" were not being populated.

Fixing this bug is not a pressing issue for me now, and could probably be a low priority,
since it is now only a matter of defensive programming, and preventing bad data from crashing
the JVM, and also an issue of the stack overflow obscuring and complicating the problem solving
process.

Thx again, Angela and Julian.

> 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