cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: default encoding in LoggingInInterceptor
Date Fri, 19 Aug 2016 09:42:38 GMT
Hi Christian

As discussed on IRC, IMHO marking core LoggingInterceptors as deprecated 
in 3.2.0 (which is what you suggested below) can be very reasonable.
The problem I've spotted now is that the ext/'new' interceptors do not 
support some features that the core/'old' interceptors do, which 
unfortunately shows the problem of having a pair of logging features.

Specifically the core interceptors can avoid logging the binary payloads
(multiparts/etc) which was a pretty annoying issue for some users - 
seeing some massive binary blobs logged (and partially due to the log 
limits) was not good.

IMHO, before the old interceptors can be marked as Deprecated we need to 
have those features that are available in the core interceptors (such as 
the one I mentioned) synced to the ext loggers

Cheers, Sergey

On 17/08/16 16:35, Christian Schneider wrote:
> On 17.08.2016 16:06, Sergey Beryozkin wrote:
>> As I said the intermediate change I proposed for 3.2.0 will help users
>> start working with your interceptors *faster*. The fact that 2 users
>> in this thread have been 'surprised' by new logging interceptors
>> should send a message that lots of users continue working with the
>> original interceptors - they may not see the advanced features you
>> worked upon in the old interceptors but they are fine.
>> Effectively there are 2 stages in the migration effort: 1) moving to
>> new nice configuration properties and 2) new package.
>> What I suggested will let migrate users to 1) in 3.2.0 immediately,
>> and with the default constructors just added - seamlessly.
>> Then in 4.0.0 if you think it is needed the core package can be
>> removed, the code put back into 'ext'. And have the stage 2) completed
>> If you are not convinced then I'm fine too. I won't be spending more
>> time trying to convince. And sorry if I'm being ignorant of the proper
>> versioning policies I know you are very good at them :-)
> I would rather like to avoid moving the code around as it introduces
> instability. Apart from that I would also rather not fiddle with the old
> logging code. People are used to how it works and what kind of messages
> it produces. So I propose to simply deprecate it and not change it any
> more during 3.x apart from important bug fixes of course.
> The fact that most people seems to not have noticed the new logging at
> all is a problem of course but I think we can announce it a bit better.
> We could also log a message when the old logging starts up that says
> that this is deprecated and people should move to the new logging module.
> Christian

Sergey Beryozkin

Talend Community Coders

View raw message