jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grégory Joseph <gregory.jos...@magnolia-cms.com>
Subject Re: JCR-1778 (was: Jackrabbit 1.5.7 release plan)
Date Sat, 18 Jul 2009 01:36:29 GMT
Hi Jukka,

On Jul 17, 2009, at 5:26 PM, Jukka Zitting wrote:

> Hi,
> 2009/7/17 Grégory Joseph <gregory.joseph@magnolia-cms.com>:
>> On Jul 15, 2009, at 12:15 PM, Jukka Zitting wrote:
>>> Well, we'd need someone to submit a patch for that... I don't know  
>>> of
>>> anyone actively working on that issue.
>> Sounds reasonable, of course. I *would* happily provide a patch, if  
>> I had
>> any idea/suggestion what direction to go to fix this.
> Take a look at the BindableRepository class and see if  you could make
> the shutdown() method remove the troublesome cache entry in
> BindableRepositoryFactory.

This seemed reasonable at first, and I have a patch that actually does  
something like that now. (from RegistryHelper, since that's where BR/ 
BRF are used)

But looking at the related JCR-411, I am now under the impression that  
there's something more broken than it appears (or perhaps something  
lacking a little inline comment here and there). In JCR-411, I see "On  
the next lookup, BindableRepositoryFactory.getObjectInstance is  
invoked". Reading this, I assumed that the javax.naming.Reference  
instance that's used tells jndi to use BRF "on the next lookup" (the  
Reference does point to BRF's classname; why else?). Well, as far as I  
can tell, that's not the case. So now, I'm left wondering what the  
jx.n.Reference is there for at all and why BRF has an instance cache  
(which after all somehow is redundant with jndi)

The reason we use this is probably legacy related, and I'll look into  
this, because it seems unnecessarily complex for us; otoh, if there's  
any insight on what *does* happen with this code, if I'm missing the  
point or if something is indeed broken, I'd be willing to help further.



View raw message