Thanks for offering to help out on this.
My belief is that most people will store the salt alongside the password as a separate column, or even embedded in the password hash column itself. For example, I've been working a little bit on supporting a unix crypt(3) format for Shiro's user passwords in INI. In *nix crypt, all information necessary to perform a password hash comparison is encoded in a single field via the Modular Crypt Format .
Granted, this isn't as secure as splitting this information up in multiple places (having it all in one place doesn't protect against brute force attacks), but I believe it is well within the 80% of the 80/20 rule for most end users.
So my expectation is that if either a separate column or embedded, that this information would be retrieved as part of the single authentication query. This would imply that the JdbcRealm should be refactored to allow for either possibility. This can typically be done w/ one query, e.g:
1. If storing a crypt-style password hash, the existing query will work as-is. The logic just needs to be changed to reconstruct the SaltedAuthenticationInfo object based on the MCF tokens.
2. If the salt is a separate column, the query will need to be something like "select password, password_salt from users where username = ?".
As for testing, we can use whatever dependencies we want (and as much of them as we want) as long as they're ASF 2.0 compatible. Since test libraries don't impact end user applications, we don't have to be as frugal with them. Feel free to use whatever mechanism you prefer!
Does this help?