Hi
This looks like the same (or similar) issue which was reported at
https://issues.apache.org/jira/browse/CXF-4571
and the trace suggests that WSDiscoveryServerListener is loaded eagerly
which is where NPE is originating. I guess JAXWS server bean may set a
property to let the listener to
Interesting…. I would have expected CXF to generate the message element at
least. Although I guess that is redundant with the fault:message that would
already be there.
The main issue I have with not checking for setters is that we'd have no way to
use the fault on the client side. Since
On Oct 16, 2012, at 10:33 PM, Yi Xiao xiaoyijhondeve...@gmail.com wrote:
Could someone shed some light on the issue? thank you very much.
Welcome to the world of implementing specs…. If there are multiple ways to
interpret the spec and the TCK for the spec doesn't explicitly test a
On Oct 17, 2012, at 4:13 PM, marcin.kasinski marcin.kasin...@gmail.com wrote:
Sorry but I don't get it.
Is it CXF bug or I should set something in my spring configuration to solve
it ?
CXF bug. You can remove the cxf-services-ws-discovery-service-2.7.0.jar from
the lib dir and it should
Usually, while mapping the exception, one way is that we would expect a
faultbean is provided, with the getFaultInfo or WebFault. If not, the
things may depend. For this scenario, think CXF should generate a new JAXB
class to do the xml --- object, The original exception instance will be
used to
Hi,
If there's no FaultBean in @webFault and no getFaultInfo method in
TestException class, currently CXF will put the exception class itself as the
FaultBean, so you need ensure field in TestException could be
marshaled/unmarshalled correctly by jaxb, so just add
Hi Dan,
Thank you very much for your response :)
Yes, as you said, maybe the spec does not explain it clearly leading to the
difference in each implementation, I will double check it.
As RI and axis2 dispatch the message to endpoint and there are many users
use them before, now want to migrate
Hi,
I'm -1 to change CXF behavior if it's just the vague part of the spec which
lead to different implementation, as we also have a huge user base of CXF
community who mostly like depend current CXF behavior.
Freeman
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red
