Actually, now that I look at it, I can just use an inner class with ExtendedLoggerWrapper to get at those protected methods I mentioned. I mean, that appears to be the point of it! Let me see if it does everything I needed.
On 9 September 2014 20:08, Matt Sicker <[email protected]> wrote: > Now that I'm looking at this, what's the point of all the methods that > take a FQCN instead of having just the ones in ExtendedLogger? I'm not sure > why we didn't just use a field in AbstractLogger in the first place. > > On 9 September 2014 19:14, Matt Sicker <[email protected]> wrote: > >> 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]> >> > > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
