jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: JCR-1778 (was: Jackrabbit 1.5.7 release plan)
Date Mon, 20 Jul 2009 13:24:04 GMT
2009/7/18 Grégory Joseph <gregory.joseph@magnolia-cms.com>:
> 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?).

that depends on the implementation of javax.naming.Context, i.e. your
jndi provider,

> 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 cache in BRF makes sure that there's only one rep instance per
see JCR-411 for more information.


> 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.
> Cheers,
> -g

View raw message