You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Ivan <xh...@gmail.com> on 2013/03/18 08:33:21 UTC
CXF-4893 Downgrade the log level for buildServiceFromWSDL and
buildServiceFromClass in the o.a.cxf.service.factory.ReflectionServiceFactoryBean
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] http://cxf.apache.org/faq.html#FAQ-AreJAXWSclientproxiesthreadsafe%3F
--
Ivan
Re: CXF-4893 Downgrade the log level for buildServiceFromWSDL and
buildServiceFromClass in the o.a.cxf.service.factory.ReflectionServiceFactoryBean
Posted by Ivan <xh...@gmail.com>.
See my comments <ivan></ivan> ;-)
On 2013-3-18, at 下午5:03, Ivan wrote:
> Hi,
>
> Firstly, I agree that, outputing which WSDL file is used is important for
> the end users, so I would suggest to do that in the ServiceImpl, think we
> should already have the WSDL info there.
It's not only print out which WSDL file is used.
What's really important is let user know building service model from WSDL
or from Class, both for server and client side.
<ivan> The messages could be still there after turning on the debug level,
just hope that we did not output this by default. </ivan>
>
> For the end users, getPort is really a common used method for web services
> client programming, we could not always talk to them, you should share one
> instance, no need to create one for each invocation. Especially, if they
> knew that, there is possible thread-safe issue here, I did not think each
> developer would like to dig into that, and check whether his scenario is
> included in those exception list.
Well, if customer wanna use some framework, IMO they do need use the
framework with proper way.
Even customer was using some similar framework before, they should realize
that CXF is different software and really shouldn't expect everything is
exactly same as before, just my PERSONAL opinion here.
<ivan>Hmm, I am thinking that, it is better that we could make the users
feel convenient, not ask them to change for us. It is also my personal idea
;-) </ivan>
>
> Also from Java EE side, it is allowed to inject/lookup the Service and sub
> service class in the managed classes, which means we will have users to
> program their applications with this style.
>
> And yes, the perforamce may not a big issue here, and the key thing is
> that, lots of messages are there in the log files. We could also talk to
> the users to change the logging level, while just thinking that, whether
we
> could do that prior to uses ask that.
We have lots of logs with different Level, specify a log with reasonable
level is the way how log works, customer will see log anyway. For this
specific case, it has been INFO level from very beginning and I do think
it's reasonable as I already mentioned. I can't really understand why do
you think this specific INFO log will cause customer concern but not other
INFO logs.
<ivan>
For the log level, the description in log4j wiki is, it looks to me that,
the creating service logging is more likely belong to DEBUG level. WDYT ?
*INFO* Interesting runtime events (startup/shutdown). Expect these to be
immediately visible on a console, so be conservative and keep to a minimum.
*DEBUG* Detailed information on the flow through the system. Expect these
to be written to logs only.
[1] http://en.wikipedia.org/wiki/Log4j
Also, I googled the cxf+log+ReflectionServiceFactoryBean, and think I am
not the only person has this issue, see the links below.
[1]
http://cxf.547215.n5.nabble.com/Suppress-console-output-when-using-CXF-td556295.html
[2] http://osdir.com/ml/users/2010-02/msg07906.html
[3]
http://cxf.547215.n5.nabble.com/logging-behavior-of-the-client-side-td551954.html
[4] http://cxf.547215.n5.nabble.com/Creating-Service-Logs-td4439679.html
[5] http://comments.gmane.org/gmane.comp.apache.cxf.user/21449
Anyway, think I could tell the customers to change the logging level for
this. IMHO, this is not a solution, just kind of a workaround.
</ivan>
2013/3/18 Jason Pell <jp...@apache.org>
> For what it's worth I agree completely with Freeman. You can always
> shut down just these specific INFO logs in your log4j.properties
> anyway, set it to WARN level instead so you don't get that stuff.
>
> On Mon, Mar 18, 2013 at 9:02 PM, Freeman Fang <fr...@gmail.com>
> wrote:
> > my comment inline
> >
> > On 2013-3-18, at 下午5:03, Ivan wrote:
> >
> >> Hi,
> >>
> >> Firstly, I agree that, outputing which WSDL file is used is important
> for
> >> the end users, so I would suggest to do that in the ServiceImpl, think
> we
> >> should already have the WSDL info there.
> > It's not only print out which WSDL file is used.
> > What's really important is let user know building service model from
> WSDL or from Class, both for server and client side.
> >>
> >> For the end users, getPort is really a common used method for web
> services
> >> client programming, we could not always talk to them, you should share
> one
> >> instance, no need to create one for each invocation. Especially, if they
> >> knew that, there is possible thread-safe issue here, I did not think
> each
> >> developer would like to dig into that, and check whether his scenario is
> >> included in those exception list.
> > Well, if customer wanna use some framework, IMO they do need use the
> framework with proper way.
> > Even customer was using some similar framework before, they should
> realize that CXF is different software and really shouldn't expect
> everything is exactly same as before, just my PERSONAL opinion here.
> >
> >>
> >> Also from Java EE side, it is allowed to inject/lookup the Service and
> sub
> >> service class in the managed classes, which means we will have users to
> >> program their applications with this style.
> >>
> >> And yes, the perforamce may not a big issue here, and the key thing is
> >> that, lots of messages are there in the log files. We could also talk to
> >> the users to change the logging level, while just thinking that,
> whether we
> >> could do that prior to uses ask that.
> > We have lots of logs with different Level, specify a log with reasonable
> level is the way how log works, customer will see log anyway. For this
> specific case, it has been INFO level from very beginning and I do think
> it's reasonable as I already mentioned. I can't really understand why do
> you think this specific INFO log will cause customer concern but not other
> INFO logs.
> >>
> >> Thanks.
> >>
> >>
> >> 2013/3/18 Freeman Fang <fr...@gmail.com>
> >>
> >>> 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: http://fusesource.com | http://www.redhat.com/
> >>> Twitter: freemanfang
> >>> Blog: http://freemanfang.blogspot.com
> >>> http://blog.sina.com.cn/u/1473905042
> >>> 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]
> >>> http://cxf.apache.org/faq.html#FAQ-AreJAXWSclientproxiesthreadsafe%3F
> >>>>
> >>>> --
> >>>> Ivan
> >>>
> >>>
> >>
> >>
> >> --
> >> Ivan
> >
>
--
Ivan
Re: CXF-4893 Downgrade the log level for buildServiceFromWSDL and
buildServiceFromClass in the o.a.cxf.service.factory.ReflectionServiceFactoryBean
Posted by Jason Pell <jp...@apache.org>.
For what it's worth I agree completely with Freeman. You can always
shut down just these specific INFO logs in your log4j.properties
anyway, set it to WARN level instead so you don't get that stuff.
On Mon, Mar 18, 2013 at 9:02 PM, Freeman Fang <fr...@gmail.com> wrote:
> my comment inline
>
> On 2013-3-18, at 下午5:03, Ivan wrote:
>
>> Hi,
>>
>> Firstly, I agree that, outputing which WSDL file is used is important for
>> the end users, so I would suggest to do that in the ServiceImpl, think we
>> should already have the WSDL info there.
> It's not only print out which WSDL file is used.
> What's really important is let user know building service model from WSDL or from Class, both for server and client side.
>>
>> For the end users, getPort is really a common used method for web services
>> client programming, we could not always talk to them, you should share one
>> instance, no need to create one for each invocation. Especially, if they
>> knew that, there is possible thread-safe issue here, I did not think each
>> developer would like to dig into that, and check whether his scenario is
>> included in those exception list.
> Well, if customer wanna use some framework, IMO they do need use the framework with proper way.
> Even customer was using some similar framework before, they should realize that CXF is different software and really shouldn't expect everything is exactly same as before, just my PERSONAL opinion here.
>
>>
>> Also from Java EE side, it is allowed to inject/lookup the Service and sub
>> service class in the managed classes, which means we will have users to
>> program their applications with this style.
>>
>> And yes, the perforamce may not a big issue here, and the key thing is
>> that, lots of messages are there in the log files. We could also talk to
>> the users to change the logging level, while just thinking that, whether we
>> could do that prior to uses ask that.
> We have lots of logs with different Level, specify a log with reasonable level is the way how log works, customer will see log anyway. For this specific case, it has been INFO level from very beginning and I do think it's reasonable as I already mentioned. I can't really understand why do you think this specific INFO log will cause customer concern but not other INFO logs.
>>
>> Thanks.
>>
>>
>> 2013/3/18 Freeman Fang <fr...@gmail.com>
>>
>>> 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: http://fusesource.com | http://www.redhat.com/
>>> Twitter: freemanfang
>>> Blog: http://freemanfang.blogspot.com
>>> http://blog.sina.com.cn/u/1473905042
>>> 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]
>>> http://cxf.apache.org/faq.html#FAQ-AreJAXWSclientproxiesthreadsafe%3F
>>>>
>>>> --
>>>> Ivan
>>>
>>>
>>
>>
>> --
>> Ivan
>
Re: CXF-4893 Downgrade the log level for buildServiceFromWSDL and buildServiceFromClass in the o.a.cxf.service.factory.ReflectionServiceFactoryBean
Posted by Freeman Fang <fr...@gmail.com>.
my comment inline
On 2013-3-18, at 下午5:03, Ivan wrote:
> Hi,
>
> Firstly, I agree that, outputing which WSDL file is used is important for
> the end users, so I would suggest to do that in the ServiceImpl, think we
> should already have the WSDL info there.
It's not only print out which WSDL file is used.
What's really important is let user know building service model from WSDL or from Class, both for server and client side.
>
> For the end users, getPort is really a common used method for web services
> client programming, we could not always talk to them, you should share one
> instance, no need to create one for each invocation. Especially, if they
> knew that, there is possible thread-safe issue here, I did not think each
> developer would like to dig into that, and check whether his scenario is
> included in those exception list.
Well, if customer wanna use some framework, IMO they do need use the framework with proper way.
Even customer was using some similar framework before, they should realize that CXF is different software and really shouldn't expect everything is exactly same as before, just my PERSONAL opinion here.
>
> Also from Java EE side, it is allowed to inject/lookup the Service and sub
> service class in the managed classes, which means we will have users to
> program their applications with this style.
>
> And yes, the perforamce may not a big issue here, and the key thing is
> that, lots of messages are there in the log files. We could also talk to
> the users to change the logging level, while just thinking that, whether we
> could do that prior to uses ask that.
We have lots of logs with different Level, specify a log with reasonable level is the way how log works, customer will see log anyway. For this specific case, it has been INFO level from very beginning and I do think it's reasonable as I already mentioned. I can't really understand why do you think this specific INFO log will cause customer concern but not other INFO logs.
>
> Thanks.
>
>
> 2013/3/18 Freeman Fang <fr...@gmail.com>
>
>> 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: http://fusesource.com | http://www.redhat.com/
>> Twitter: freemanfang
>> Blog: http://freemanfang.blogspot.com
>> http://blog.sina.com.cn/u/1473905042
>> 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]
>> http://cxf.apache.org/faq.html#FAQ-AreJAXWSclientproxiesthreadsafe%3F
>>>
>>> --
>>> Ivan
>>
>>
>
>
> --
> Ivan
Re: CXF-4893 Downgrade the log level for buildServiceFromWSDL and
buildServiceFromClass in the o.a.cxf.service.factory.ReflectionServiceFactoryBean
Posted by Ivan <xh...@gmail.com>.
Hi,
Firstly, I agree that, outputing which WSDL file is used is important for
the end users, so I would suggest to do that in the ServiceImpl, think we
should already have the WSDL info there.
For the end users, getPort is really a common used method for web services
client programming, we could not always talk to them, you should share one
instance, no need to create one for each invocation. Especially, if they
knew that, there is possible thread-safe issue here, I did not think each
developer would like to dig into that, and check whether his scenario is
included in those exception list.
Also from Java EE side, it is allowed to inject/lookup the Service and sub
service class in the managed classes, which means we will have users to
program their applications with this style.
And yes, the perforamce may not a big issue here, and the key thing is
that, lots of messages are there in the log files. We could also talk to
the users to change the logging level, while just thinking that, whether we
could do that prior to uses ask that.
Thanks.
2013/3/18 Freeman Fang <fr...@gmail.com>
> 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: http://fusesource.com | http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> 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]
> http://cxf.apache.org/faq.html#FAQ-AreJAXWSclientproxiesthreadsafe%3F
> >
> > --
> > Ivan
>
>
--
Ivan
Re: CXF-4893 Downgrade the log level for buildServiceFromWSDL and buildServiceFromClass in the o.a.cxf.service.factory.ReflectionServiceFactoryBean
Posted by Daniel Kulp <dk...@apache.org>.
I have to agree with Freeman as well. This is an informational log, not a debug log. It provides very important behavior about what the system is doing and how it's going to behave. This is likely the most important message we log anywhere at any time from a support standpoint.
Also, since we're pretty much a bunch of volunteers, it's very important for us to make supporting CXF as easy as possible. This is an important part of that. Having to explain to users how to turn on various log options and such to get this information would make the support burden a lot higher. I'd much rather have it logged and possibly add information to the logging page about how to turn if off if it bothers someone. 90% of the time, it won't bother anyone and, as I said, this if very important information to have.
Dan
On Mar 18, 2013, at 4:12 AM, Freeman Fang <fr...@gmail.com> wrote:
> 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: http://fusesource.com | http://www.redhat.com/
> Twitter: freemanfang
> Blog: http://freemanfang.blogspot.com
> http://blog.sina.com.cn/u/1473905042
> 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] http://cxf.apache.org/faq.html#FAQ-AreJAXWSclientproxiesthreadsafe%3F
>>
>> --
>> Ivan
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXF-4893 Downgrade the log level for buildServiceFromWSDL and buildServiceFromClass in the o.a.cxf.service.factory.ReflectionServiceFactoryBean
Posted by Freeman Fang <fr...@gmail.com>.
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: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
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] http://cxf.apache.org/faq.html#FAQ-AreJAXWSclientproxiesthreadsafe%3F
>
> --
> Ivan