After looking at this, and the original comment, I _think_ I see what you are getting at.
We should defiantly NOT be dropping/ignoring any exceptions. After my first read through, I was thinking this was a logging level issue. Liang, can you open a JIRA issue <http://issues.apache.org/jira/browse/SHIRO>, and include I high level overview of how we could reproduce this in a test? Of course providing a test would be ideal! On Thu, Dec 15, 2016 at 1:55 PM, Shawn McKinney <[email protected]> wrote: > > > On Dec 15, 2016, at 11:21 AM, Brian Demers <[email protected]> > wrote: > > > > There have been a couple issues on either side of this. > > > > These exceptions should be logged, as 'debug' (if i remember correctly). > Increasing the default logging can cause log spam in the cases where > multiple realms are enabled, and one is misbehaving (db is down, or some > network issue). > > > > The common (and valid complain) is similar to your as this does not > provide a good first experience, when setting up Shiro for the first time. > > > > Does anyone have any ideas on ways to both eliminate the log spam and > provide make it easier to troubleshoot for new installs? > > > > Hello, > > It has been my experience that a security handler should either log or > forward a downstream exception, but not both, to prevent the kind of log > spam you are referring to. Furthermore exceptions from downstream > resources, i.e. database / ldap servers, should probably be converted into > a common exception format, i.e. mysecurityhandlerexception, but the > original exception should always be included as a member of the new > exception class. > > That way information isn’t duplicated (in the logs) or lost, across the > entire lifecycle of the exception. > > HTH, > Shawn
