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
