You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Simon Kissane <sk...@medallia.com> on 2018/07/17 05:52:39 UTC
Customisation of Slf4jEventSender
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
Re: Customisation of Slf4jEventSender
Posted by Colm O hEigeartaigh <co...@apache.org>.
Yes please submit a JIRA and pull request for both these issues.
Colm.
On Tue, Jul 17, 2018 at 6:52 AM, Simon Kissane <sk...@medallia.com>
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