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 Fri, 31 Aug 2007 15:20:30 GMT

    [ 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

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