Hi Enrico,
> There is a method to force JAAS to reload the system property. > > Something like Configuration.getConfiguration().refresh() Great to know! Thanks! > You have to call that method after changing the system property Cheers, -D > 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 >>
