> From: Alan Bateman <[email protected]> > To: Andrew Guibert <[email protected]>, [email protected] > Date: 05/10/2017 07:32 AM > Subject: Re: Proposal: > javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() > > On 08/05/2017 23:27, Andrew Guibert wrote: > > > : > > > > I am not sure why the "no resetting" restriction is on the NamingManager > > API in the first place. Is anyone aware why the API has this restriction? > > In any case, the solution outlined above seems rather messy (as it only > > solves the problem by mitigating a classloader leak), so I would like to > > propose the following addition to the NamingManager API: > > > > > I checked with one of the engineers that worked on the JNDI API a long > time ago and there doesn't seem to be any significant reason to disallow > it be changed. > > Looking at it now then it might be simpler to change > setInitialContextFactoryBuilder to allow a new builder to be set rather > than introducing a clearXXX method. I can't imagine anything but tests > relying on IllegalStateException to be thrown if already set. A variant > to explore is setting the builder to a placeholder InitialContextFactory > rather than null.
Thank you for checking on this Alan! I agree relaxing the setXXX method would be cleaner than introducing a new clearXXX method, but I wasn't sure what the policy was on behavior changes to existing APIs. But I think you are right, there probably isn't any "real" code that depends on this behavior (aside from code like mine that forcibly clears if an ISE is thrown). > So is your plan to proposal a patch and tests for this? I need to check with my management to get all the legal approvals before proposing a patch, so it might take a while. Since it's likely a very small code change I won't be offended if someone else proposes the patch for me =)
