You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Grégory Joseph <gr...@magnolia-cms.com> on 2009/07/17 17:14:54 UTC
Re: JCR-1778 (was: Jackrabbit 1.5.7 release plan)
On Jul 15, 2009, at 12:15 PM, Jukka Zitting wrote:
> 2009/7/14 Grégory Joseph <gr...@magnolia-cms.com>:
>> Not strictly a backport, since as far as I know this is still
>> opened for
>> 1.6/2.0, but is there any chance JCR-1778 would get fixed ?
>
> 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.
Cheers,
-g
Re: JCR-1778 (was: Jackrabbit 1.5.7 release plan)
Posted by Stefan Guggisberg <st...@gmail.com>.
2009/7/18 Grégory Joseph <gr...@magnolia-cms.com>:
> Hi Jukka,
>
>
> On Jul 17, 2009, at 5:26 PM, Jukka Zitting wrote:
>
>> Hi,
>>
>> 2009/7/17 Grégory Joseph <gr...@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
configuration.
see JCR-411 for more information.
cheers
stefan
>
> 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
>
Re: JCR-1778 (was: Jackrabbit 1.5.7 release plan)
Posted by Grégory Joseph <gr...@magnolia-cms.com>.
Hi Jukka,
On Jul 17, 2009, at 5:26 PM, Jukka Zitting wrote:
> Hi,
>
> 2009/7/17 Grégory Joseph <gr...@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.
Cheers,
-g
Re: JCR-1778 (was: Jackrabbit 1.5.7 release plan)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
2009/7/17 Grégory Joseph <gr...@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.
BR,
Jukka Zitting