> It's useful to think through the whole scenario. If we actually > prevented this, it'd mean that Shiro couldn't be reconfigured > dynamically within the same JVM. Logging a warning perhaps (I'm sure > there are at least some info messages on this even currently) but how > much configuration would be enough configuration to trigger a warning? > I'll certainly evaluate concrete suggestions to mitigate this but > until then it's business as usual: if you run unit tests within the > same JVM better make sure they don't interfere with each other.
The thing is - I *though* I was making sure they don't interfere. I reinitialized Shiro on every test, and it turns out that you can't dynamically reconfigure Shiro within the same JVM. However, this was a wrong assumption, and a log message would've helped on it. Not to mention a more helpful exception... /Janne
