Hi Christian,
Why can't the existing/original loggers be modified instead of starting
a migration effort from one package to another package ?
What are the side-effects you are referring too ? Having a default
constructor is needed for sure - one can just to default to whatever is
required. What else ?
3.2.0 is a new major master branch. IMHO we need to merge the new/'ext'
feature/interceptors into the existing feature/interceptor and document
what the migration effort might be instead of asking the users to do
even bigger migration (+ new package)
Funny I was just having this discussion re the live logging arguing how
it is important to avoid introducing LiveLoggingFeature & Live logging
interceptors to avoid the duplication not knowing myself we already have
two sets of Logging interceptors/features :-)
Sergey
On 17/08/16 13:08, Christian Schneider wrote:
Initially I planned to remove the old logging support completely but the
effects on existing users were to big.
So I kept both for now but on the long run we should remove the old
logging support.
As the new logging is in a separate module I was not able to change the
old logging to use the new interceptors.
So I opted to rather keep them totally separate from each other. We
could mark the old logging classes as deprecated though and point users
to the new logging module.
Christian
On 17.08.2016 14:03, Sergey Beryozkin wrote:
Oh, I did not know we have two LoggingIn/OutInterceptor classes...
Why can;t have a single LoggingInInterceptor with as many constructors
as needed ?
Sergey
On 17/08/16 12:55, Christian Schneider wrote:
If you want to use the LoggingInInterceptor then you have to inject the
constructor with a LogEventSender. This allows
to use the interceptor with something different than slf4j.
Christian
On 17.08.2016 12:52, Vjacheslav V. Borisov wrote:
2016-08-17 11:19 GMT+04:00 Christian Schneider
<ch...@die-schneider.net>:
You should also take a look at the new Logging support in:
https://github.com/apache/cxf/tree/master/rt/features/logging
http://www.liquid-reality.de/display/liquid/2015/06/08/Enter
prise+ready+request+logging+with+CXF+3.1.0+and+elastic+search
The new logging feature should also make it easier to customize the
way to
output the message.
Christian, this is not related to my original question, but i noticed
that
in new logging feature I cannot configure to do only request logging?
E.g. in original logging feature I can
1) configure <cxf:logging/> in cxf:bus and see all (request and
response)
logs
2) can configure individual interceptors, e.g. to log only requst
<jaxrs:server
<jaxrs:inInterceptors>
<bean
class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
However, in new logging feature I cannot reference
org.apache.cxf.ext.logging.LoggingInInterceptor, becouse of
Failed to instantiate
[org.apache.cxf.ext.logging.LoggingInInterceptor]:
No default constructor found; nested exception is
java.lang.NoSuchMethodException:
org.apache.cxf.ext.logging.LoggingInInterceptor.<init>()
And also do not see how could I configure
org.apache.cxf.ext.logging.LoggingFeature
to do only request logging.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
