A few weeks ago, I blogged about how the new <jdbc-user-service> in Spring 2.0 is hard-coded to a specific set of SQL for querying user information and authorities. This, in my opinion, effectively rendered <jdbc-user-service> useless for any application whose user details are kept in a schema that isn't what <jdbc-user-service> expects.
It was suggested by some that it's easy enough to configure a JdbcDaoImpl as a <bean> and wire it into <authentication-provider>. That's true...and since JdbcDaoImpl can be configured with custom SQL, it would solve my problem. Even so, I still argue that <jdbc-user-service> should either offer the same SQL customization or it should be removed from Spring 2.0's configuration schema.
After creating an issue (SEC-703), submitting a patch, asking everyone I met to vote for SEC-703, and waiting patiently, I've finally got my wish. As of today, SEC-703 has been closed with a resolution that adds new attributes to <jdbc-user-service> to allow custom SQL to be specified.
Many thanks to the 100 or so people I've spoken to at user groups in the last month for enduring my rant on SEC-703 and to the 4 people who actually voted for that issue. But mostly, thanks goes to Luke Taylor who committed the change that made this possible. When you download Spring Security 2.0, you'll be downloading a little bit of my code.
Speaking of Spring Security 2.0, it looks like a release is imminent. There are no more open issues and it appears that the 2.0.0 release has been "released" in JIRA. By the time you read this, it may already be available.
If you'd like to hear more about Spring Security 2.0 and how it is so much better than Acegi (not to mention how it will make a huge difference in the lives of thousands of fairies), I'll be presenting Spring Security 2.0 at the upcoming No-Fluff/Just-Stuff events in Seattle, Oklahoma City, and Dallas.
