jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: [jira] Commented: (JCR-1099) jcr2spi NodeEntryImpl.getPath() blows stack due to getIndex() calling itself
Date Fri, 31 Aug 2007 16:37:50 GMT
hi david

jira is down again :(
here some thoughts, that i would have put into the issue....

//---------------------------------------------------------------------

so, you are having:

jcr2spi -> your spi impl -> spi2jcr -> jackrabbit.

is that correct?
in that case i would like you to check, whether it makes a difference if 
you omit 'your spi impl'. and if it indeed would make
a difference i suggest, that you provide some analysis on this.

it's perfectly possible, that the jcr2spi does not behave properly, but 
i don't like guessing.
and maybe its the SPI that unintentionally leaves room for 
interpretation (or jcr2spi is expecting the wrong thing)....

//---------------------------------------------------------------------

kind regards
angela




David Rauschenbach (JIRA) wrote:
>     [ 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
> 

Mime
View raw message