That is true, it is a bit different. I think were both aproaches meet is
that we should be able to control which extensions and features are loaded.
Simply loading everything is too coarse grained. For extensions the
default of loading every extension may make sense as they are often
things like
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
See my comments ;-)
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 f
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 wrote:
> my comment inline
>
> On 2013-3-18, at 下午5
Hi,
I recently ran into a problem with the BooleanGetterPlugin when using the
generated classes in a Spring MVC webpage. (This is a legacy application, don't
ask... :-)) MVC needs to use a getter for booleans so we generate them with
-Xbg extension. Unfortunately, we also have a lot of existin
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 fil
Hi Christian,
your use case seems like creating some kind of automatic policy
derivation mechanism based on other properties of the scenario. It's
an interesting approach that makes some scenarios more flexible as
they don't need to explicitly use policies but could make the thing
complex as we don
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
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
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
10 matches
Mail list logo
