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