I can even simplify the solution even more by removing classes. I could get this solution to work with 1 Log interface, 1 LogFactory abstract class, and 3 Log implementations - Slf4JLog, JdkLog, NoOpLog, all methods 1 line each - easy peasy.
That would be it - 5 files total. That would be as simple as it could get, again with no class loading issues. Wouldn't this be acceptable? On Tue, Jul 15, 2008 at 10:02 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: > That is, the following: > > //SL4J native API > Logger log = LoggerFactory.getLogger(getClass()); > > is functionally identical to this: > > //JSecurity wrapper API: > Log log = JSecurityLogFactory.getLog(getClass()); > > _if_ SLF4J is anywhere the classpath. If not, there is graceful > degredation. This solution does not use reflection. > > On Tue, Jul 15, 2008 at 10:00 AM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> Ok, I committed a solution that will definitely work with NO class >> loader issues. >> >> It uses static linking just like SLF4J. Now there should be no more >> arguments against this solution due to potential CL issues - they >> can't occur now. >> >> Please do an SVN update and look at JSecurityLogFactory again. I've >> tested this and works well. >> >
