Hi Christian
On 17/08/16 14:25, Christian Schneider wrote:
On 17.08.2016 15:17, Sergey Beryozkin wrote:
On 17/08/16 14:13, Christian Schneider wrote:
On 17.08.2016 15:08, Sergey Beryozkin wrote:
Letting the old classes extend the new ones is also not possible as
core
can not depend on the logging feature jar.
Then we need to solve it differently. Move the ext code into the core
and have the ext interceptors and feature simply extend that code
That will mean a gentler migration effort.
I do not agree. In a major version we should remove old stuff. The time
to migrate is in 3.1 where both logging features exist.
So people can gradually move to the new logging. Then when they complete
the migration they switch to CXF 4 without any changes. This is why I
try to create new functionality in a minor version and remove the old
one in a major version.
Of course this can mean that a major version has 0 new features but that
is exactly the purpose outside of marketing.
You keep operating with some academic terms which have little do with
the practicalities.
Imagine what will happen if you get rid of the core package as far as
the external tooling and 3rd party use of this one of the most often
used CXF feature.
Likewise I'm -1 on removing the core code from 3.2.0. Lets have 2 sets
of interceptors
Makes sense. So lets wait until a real 4.0 version and remove it then.
Which leave people more time to migrate. In the mean time I propose to
mark the old logging classes as deprecated so people are alerted that
they will be removed later.
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 :-)
Sergey
Sergey
Christian
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
