I think logging is not a core element of CXF so I would like to move it
out of cxf core. This is why I created the new logging in a separate module.
3.2.0 is a minor release. So I am not sure if we should remove something
like logging from core in this release. We could try to merge the old
and new logging but I think it might be better to just deprecate the old
logging and leave it unchanged.
I am aware that duplicating stuff is not good generally but as I would
just remove the old logging in the next major release I think this might
be ok.
Introducing the new logging in 3.1.0 allows users to migrate gradually
as the old logging remains unchanged until the next major release.
What do you refer to with LiveLogging? Somehow I seem to have missed the
discussion.
Christian
On 17.08.2016 14:21, Sergey Beryozkin wrote:
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
<[email protected]>:
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.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
