Weekend ;) We defiantly should be logging the exception, at what level is probably a (though related) different discussion.
A test case is probably the first thing we need. Thanks for opening the issue! On Mon, Dec 19, 2016 at 12:04 AM, 喂喂喂 <[email protected]> wrote: > Hey, I have open a issue <https://issues.apache.org/jira/browse/SHIRO-606>, > but there is no progress on the issue and no other JIRA user views the > issue. > > > ------------------------------------------------------------ > ------------------------------------------------------------ > ----------------- > > 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 > > >
