I'm making some changes to log4j-jul to reduce redundant time spent constructing a LogRecord that I don't even want to use most of the time. However, the ExtendedLogger interface (which I need to use at the very least so that I can set the fqcn to java.util.logging.Logger) only provides a single version of logMessage (unlike AbstractLogger which has a bunch), and several methods like catching(), throwing(), etc., all depend on protected methods in AbstractLogger that I'd rather not re-implement. It would be nice if I could just call the Logger methods I need, but they all get called with the wrong fqcn.
Can we use a non-static final field that contains the fqcn? If I could, I'd extend AbstractLogger myself, but I already have to extend the JUL Logger class (should have been an interface, grrr). Thus, I can't rely on AbstractLogger being the source of all these method calls. Unlike the other adapters, JUL provides more various logger calls than we even have, and I don't think ExtendedLogger was written with this scenario in mind. I don't think this should be too large an impact of a change. I'm going to push up a proposal, but feel free to veto it or offer some suggestions! -- Matt Sicker <[email protected]>
