Open GoogleCodeExporter opened 8 years ago
I'm fine with setting this to Low Priority, buy I'm not sure how.
Original comment by rob.spre...@gmail.com
on 12 Nov 2009 at 10:18
Changed to low priority and scheduled for 2.1
Original comment by chrisisbeef
on 2 Dec 2009 at 7:32
Original comment by chrisisbeef
on 20 Nov 2010 at 9:52
This is still needed. Given the changes in 2.0 to the loading, the initial
setup is no longer valid, as you can't set a logFactory any longe before
loading the security configuration. The solution to this should also address
that problem.
Original comment by rob.spre...@gmail.com
on 19 Jul 2011 at 1:56
why do we still see System.out.println instead of loggers. it would be good to
use java.util.logging instead of using Sysouts, if you won't prefer
slf4j/log4j.
something like this
use static variable
public class DefaultSecurityConfiguration implements SecurityConfiguration {
private static java.util.logging.Logger log = java.util.logging.Logger.getLogger(DefaultSecurityConfiguration.class.getName());
........
private void logSpecial(String message) {
log.log(Level.FINE, message);
}
....
}
Original comment by r.nagesh...@gmail.com
on 2 May 2014 at 8:39
This should be using at a minimum the jdk1.4 logger framework. As it stands
currently, I've got a production application, that once a quarter, I get some
complaint after a restart with regard to the loading of the ESAPI.properties
error messages emitted from DefaultSecurityConfiguration to System.out. There
is no way to override this behavior nor is there a mechanism to route this to a
specific log file. This issue has been open for well over 5 years and should
have been addressed with the 2.1.0 release.
If there is another reason why this has not addressed, please provide reasoning
to keep it outputting to System.out/System.err.
Original comment by djgraff...@gmail.com
on 13 Apr 2015 at 1:56
Original issue reported on code.google.com by
rob.spre...@gmail.com
on 12 Nov 2009 at 10:17