Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()

[Andrew Guibert]

> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: Andrew Guibert <aguibert at us.ibm.com>, core-libs-dev at openjdk.java.net
> 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 =)