Yes please submit a JIRA and pull request for both these issues. Colm.
On Tue, Jul 17, 2018 at 6:52 AM, Simon Kissane <[email protected]> wrote: > Hello > > The class org.apache.cxf.ext.logging.slf4j.Slf4jEventSender hardcodes the > logger category: > String cat = "org.apache.cxf.services." + > event.getPortTypeName().getLocalPart() > + "." + event.getType(); > > Actually, I wanted to send it to a different logger category. When using > the now deprecated > org.apache.cxf.interceptor.Logging{In,Out}Interceptor you could override > the logger name by > subclassing and overriding the protected Logger getLogger() method. > > But the only way I can see to do this, is to copy/paste the > Slf4jEventSender class and modify it. > Which obviously is less than ideal. > > The reason behind this, is operationally we are expecting a particular > logging category. > It would be easier if the CXF upgrade could be done without changing the > logging category. > (Strictly speaking, I could continue using the old deprecated logging > interceptor, but I think > it is better to remove reliance on deprecated features whenever possible; > plus, using > deprecated classes is difficult since we build with -Werror, particularly > considering > https://bugs.openjdk.java.net/browse/JDK-8032211 and this application is > still on Java 8.) > > On another point, after getting the Logger, the send() method should then > do: > if (!logger.isInfoEnabled()) > return; > It is a waste of time to construct a log message if the logger isn't > enabled at that level. > This is generally a best practice with SLF4J, see > https://www.slf4j.org/faq.html#logging_performance > > Should I open an issue in the JIRA for the above? > > Thank you > > Simon Kissane > Software Engineer | ❖ Medallia, Inc. > Australia -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
