2009/7/18 Grégory Joseph <[email protected]>: > Hi Jukka, > > > On Jul 17, 2009, at 5:26 PM, Jukka Zitting wrote: > >> Hi, >> >> 2009/7/17 Grégory Joseph <[email protected]>: >>> >>> 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 >
