There is a method to force JAAS to reload the system property. Something like Configuration.getConfiguration().refresh()
You have to call that method after changing the system property Hope that helps Enrico Il gio 9 gen 2020, 20:05 Damien Diederen <ddiede...@sinenomine.net> ha scritto: > > Hi Arpit, Máté, > > Arpit wrote: > > > The solution is to pass JAAS file > > with -Djava.security.auth.login.config=/path/to/jaas.conf. > > Okay—good. > > > Using System.setProperty does not work for me. > > Ah, I see. And I'm not surprised; I think Máté is on the right track: > > >> I also faced this exception not long ago. I think it is an edge case, > most > >> probably you have something else, but still... maybe it helps: > >> > >> I tried to write a unit test which dynamically generated multiple > >> jaas.conf files. Then I was setting the > >> java.security.auth.login.config system property to the config file I > needed > >> in the given testcase, and when I tried to establish a ZooKeeper > connection > >> in the unit test, I also got the same exception that you got. > >> > >> The problem was, that the security configuration file I referred in the > >> java.security.auth.login.config system property file was read only once, > >> then stored in memory. And it haven't got reloaded, even if the file (or > >> its path in the system property) changed. > > My understanding is that the property is read very early after "VM boot" > (the first time any class tries to access the java.security.Provider): > the resource it points to is parsed at that point, and the property > "never" checked again. > > (It *may* be possible to flush the "Spi" or something, but it's clearly > not the kind of usage it was designed for.) > > >> Maybe the best in this case is to > >> specify separate JAAS config sections for each tests and use a single > >> JAAS.conf file per JVM. > > That's probably the easiest if the set is enumerable. > > "Real dynamism" might require overriding the "Spi" or "Provider," but > that's probably overkill for a few tests. > > (Now that I think of it… our tests are already run under the JMockit > agent, so live-patching JAAS methods using mockit.MockUp might be > another option :) > > Anyway. It looks like setting the property externally worked for Arpit. > > Cheers, -D >
