Please note that this resolution does not indicate one way or another a conclusion on the type-hiearchy discussion in the other thread. This issue just makes the existing LdapRealm consistent in behavior with all of the other out-of-the-box Realm implementations that catch and propagate exceptions.
If the community feels that we still need a DAO exception hierarchy, please surface it on the other discussion thread. On Thu, Jan 14, 2010 at 3:13 PM, Les Hazlewood (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/SHIRO-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Les Hazlewood resolved SHIRO-120. > --------------------------------- > > Resolution: Fixed > Fix Version/s: 1.0 > > Caught the NamingExceptions and propagated them as Shiro-specific exceptions > (either AuthenticationException or AuthorizationException). > >> AbstractLdapRealm's doGetAuthenticationInfo catches naming exception, but >> then only logs a message >> -------------------------------------------------------------------------------------------------- >> >> Key: SHIRO-120 >> URL: https://issues.apache.org/jira/browse/SHIRO-120 >> Project: Shiro >> Issue Type: Bug >> Components: Authentication (log-in) >> Affects Versions: Incubation >> Reporter: Jonathan Hall >> Fix For: 1.0 >> >> >> I have a class that extends the ActiveDirectoryRealm in order to perform >> authentication against Active Directory, my class then uses database tables >> to support the authorisation of the authenticated subject. What I have >> found is that calls to the super doGetAuthenticationInfo can return a null >> in the event of a communication problem with the Active Directory server. >> On further investigation, I found that the doGetAuthenticationInfo method in >> AbstractLdapRealm catches a javax.naming.NamingException and then logs an >> error message. As the exception has been caught and not propagated, the >> only way my derived class knows there has been a problem is through checking >> if the AuthenticationInfo is null - however the original context of the >> exception has been lost (albeit it was logged). >> It would be useful if the naming exception was allowed to propagate up or >> alternatively caught and a Shiro specific exception thrown - either way, it >> would allow descendants of ActiveDirectoryRealm to handle the exception and >> do the appropriate thing themselves. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
