cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <>
Subject Re: CXF-4893 Downgrade the log level for buildServiceFromWSDL and buildServiceFromClass in the o.a.cxf.service.factory.ReflectionServiceFactoryBean
Date Mon, 18 Mar 2013 08:12:42 GMT
As my comment in CXF-4893, I'm -1 for this change.

Moreover, that INFO is very important in several cases. For example, some metadata is only
carried by the WSDL, like ws-policy or schema validation info, you can easily run into weird
 problem that why some feature doesn't work, check that INFO log to know whether the service
model build from WSDL or Class is the first place to check.

Given the importance of that INFO, I really don't think downgrade the log level for it is
a good idea, and performance impact to print this INFO is acceptable IMO.  In CXF, the client
proxy is thread safe in most cases, so it's rare that you need create a client pool, so generally
for both client and server, you only see it once.

Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: |
Twitter: freemanfang
weibo: @Freeman小屋

On 2013-3-18, at 下午3:33, Ivan wrote:

> Hi, devs,
> I hope that we could re-consider the logging level issue for CXF-4893 about
> changing the log level for buildServiceFromWSDL and buildServiceFromClass
> in the ReflectionServiceBeanFactory class.
> The logging will be output while constructing the endpoint proxy,
> typically, this will occurs while users invoke getPort or related methods
> in the generated client stub classes.
> Yes, we should always reuse the client proxy, while considering that, the
> generated proxy is not thread-safe in some scenarios (as mentioned in link
> [1]), for the users, they may still like to create the port for each
> invocation, so it will finally have lots of messages, which will mess the
> log files and may also possible have side effection to the perf.
> If we would like to point out which wsdl file was used, think that
> ServiceImpl class is a better location, as only one ServiceImpl should be
> created in the common client codes writing practice.
> Thoughts ?
> [1]
> -- 
> Ivan

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message