On 17/08/16 13:36, Christian Schneider wrote:
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.
that is fine, you mean rt/features/logging, it is fine
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.
3.2.0 is a major release as far as I know, even though it is not 4.0.0,
it is strictly Java8, we just do not have that many new features to mark
it as 4.0.0 - but fingers crossed it will have early JAX-RS 2.1, etc. It
is a major release AFAIK
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.
+1 to remove one of the two available set of loggers.
Lets keep your new loggers they are more advanced.
In 3.2.0 IMHO it is the right time to get rid of the old code and keep
your new code only - otherwise we will need to continue fixing issues
for both sets of loggers and it will be a mess :-)
Introducing the new logging in 3.1.0 allows users to migrate gradually
as the old logging remains unchanged until the next major release.
that was fine for 3.1.0. But in 3.2.0 lets have a single set of logging
interceptors (+ feature).
But lets not make users do a package migration.
For example, in 3.2.0 we can get rid of the 'ext' package.
or keep it and have the original LoggingIn/OutInterceptors/Feature
extending the ext ones with some default properties
What do you refer to with LiveLogging? Somehow I seem to have missed the
discussion.
Lets do another discussion for this one
Sergey
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
<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/
