You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Kristian Rink <ka...@googlemail.com> on 2012/03/26 20:45:47 UTC
CXF client in (glassfish) app server: dump SOAP messages?
Folks;
I'm trying to get an Apache CXF (2.4.6) client to work with a web
service provided by one of our partners and, so far, fail. I am not
really sure why it fails, I only see that the web service in some error
situations doesn't return SOAP Faults but rather plaintext messages
which is a _rather_ helpful thing yet unfortunately something I can't
quickly fix.
However, I'm by now trying to figure out how to make CXF simply dump all
of its SOAP request and response messages for the sake of seeing what
happened. The client runs inside an application context in a Glassfish
v3.1 server and works well in most situations already. Concerning
Logging, however, I feel a bit lost. So far I already tried virtually
everything I could figure out by reading documentation, including
... adding various -D<whatever> options to my Glassfish <jvm-options> in
order to do as I intend to do,
... removing most of the logging configuration in the application
context (which natively uses slf4j and logback), and
... using the META-INF/cxf/org.apache.cxf.Logger file, both for slf4j or
for log4j.
Logback is configured by now to log virtually everything to STDOUT so
the messages should appear where everything else appears, too (in the
Glassfish server.log), yet - they don't. Spent most of the afternoon
trying, yet still I fail making the CXF output anything more verbose
than INFO statements. And I feel like giving up at the moment. Is there
anything essential I am missing here? Any hints, no matter which, are
greatly appreciated.
Thanks for your time and all the best,
Kristian
Re: CXF client in (glassfish) app server: dump SOAP messages?
Posted by Kristian Rink <ka...@googlemail.com>.
Am 26.03.2012 22:43, schrieb David Mansfield:
> It shows how the interceptors are "wired", and you should see the
> LoggingOutInterceptor (and an "in" one, on the input side) or else you
> know it's a config problem.
Indeed. I also managed to get it working now - tough stuff as most of
the rest of the application doesn't too much make use of Spring so I
ended up following the "programmatic client" approach which however
seems to work now so I am fine with that. Back to tracking down the
actual errors in the message exchange. ;)
Thanks loads for your support on that, greatly appreciated!
Kristian
Re: CXF client in (glassfish) app server: dump SOAP messages?
Posted by David Mansfield <cx...@dm.cobite.com>.
On 03/26/2012 04:37 PM, Kristian Rink wrote:
> Am 26.03.2012 22:17, schrieb David Mansfield:
>
>>> FWIW when in a (webapp) context, where would META-INF/cxf/.. have to be?
>>> By now META-INF is on the same level as WEB-INF, I suspect this should
>>> do?
>>>
>> No, I don't think so. The "META-INF" is in the "root" of each entry in
>> the classpath. For a web-app, along with all of the jars, the
>> WEB-INF/classes is on the classpath, so you need
>> WEB-INF/classes/META-INF. Of course, you should be able to put the
>> resources in a jar as well, in which case they go in the META-INF in the
>> jar.
> Thanks David, this definitely was part of the issue. By now, at the very
> least, I see a definite change in the logging spewed out with having
> anything org.apache.cxf set to Log Level "all" in logback config.
> However, I now see loads of debugging stuff including some HTTP headers
> yet the SOAP message content is still missing from the logs. Guess now
> it's about figuring out which level for which loggers.
And you need the log interceptors added to your bus. Do you see this
kind of crap in your log:
setup [PolicyOutInterceptor]
pre-logical [HolderOutInterceptor, SwAOutInterceptor,
WrapperClassOutInterceptor, SoapHeaderOutFilterInterceptor]
post-logical [SoapPreProtocolOutInterceptor]
prepare-send [MessageSenderInterceptor]
pre-stream [LoggingOutInterceptor, AttachmentOutInterceptor,
StaxOutInterceptor]
pre-protocol [WSS4JOutInterceptor]
write [SoapOutInterceptor]
marshal [BareOutInterceptor]
post-protocol [WSS4JOutInterceptorInternal]
write-ending [SoapOutEndingInterceptor]
pre-protocol-ending [SAAJOutEndingInterceptor]
pre-stream-ending [StaxOutEndingInterceptor]
prepare-send-ending [MessageSenderEndingInterceptor]
It shows how the interceptors are "wired", and you should see the
LoggingOutInterceptor (and an "in" one, on the input side) or else you
know it's a config problem.
I had great difficulty at first trying to use the "cxf.xml", but since I
was already using spring, I got it working using a different xml
referenced from my "main" spring xml.
I tried all three ways in the file, and the only one that worked at
first was the first technique, described as "don't do this"...
HTH,
David
Re: CXF client in (glassfish) app server: dump SOAP messages?
Posted by Kristian Rink <ka...@googlemail.com>.
Am 26.03.2012 22:17, schrieb David Mansfield:
>> FWIW when in a (webapp) context, where would META-INF/cxf/.. have to be?
>> By now META-INF is on the same level as WEB-INF, I suspect this should
>> do?
>>
>
> No, I don't think so. The "META-INF" is in the "root" of each entry in
> the classpath. For a web-app, along with all of the jars, the
> WEB-INF/classes is on the classpath, so you need
> WEB-INF/classes/META-INF. Of course, you should be able to put the
> resources in a jar as well, in which case they go in the META-INF in the
> jar.
Thanks David, this definitely was part of the issue. By now, at the very
least, I see a definite change in the logging spewed out with having
anything org.apache.cxf set to Log Level "all" in logback config.
However, I now see loads of debugging stuff including some HTTP headers
yet the SOAP message content is still missing from the logs. Guess now
it's about figuring out which level for which loggers.
Thanks again and all the best,
Kristian
Re: CXF client in (glassfish) app server: dump SOAP messages?
Posted by David Mansfield <cx...@dm.cobite.com>.
On 03/26/2012 04:09 PM, Kristian Rink wrote:
> Am 26.03.2012 22:01, schrieb David Mansfield:
>> Is it possible that you're not using CXF because glassfish is loading
>> the RI (metro)? I had read some things on stackoverflow pointing to the
>> necessity of putting some libraries into the endorsed dir to get
>> glassfish to use cxf. This is all a vague handwave though, I can't
>> remember the details.
> Yes I have been through this round as well by now; initially I intended
> to use Metro after all but it seems to be in no way whatsoever willing
> to work with this service whereas CXF does way better. I had to mess
> with the application classloader to make sure CXF is being seen/used indeed.
>
>> Do you have any specific log messages or stack traces that definitely
>> confirm that the CXF stack is being used?
> Yes; in case of any issues I regularly end up with messages just like this
>
> [...]
> has thrown exception, unwinding now
> org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader.
> [...]
> Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected
> character 's' (code 115) in prolog; expected '<'
> at [row,col {unknown-source}]: [1,39]
> at
> com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:639)
> at
> com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2032)
> at
> com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1117)
> at
> com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1140)
> at
> org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:138)
> ... 99 more
> |#]
> [...]
>
> ... which at least _seems_ CXF to me - the Metro traces look a bit
> different. And as I generally and totally fail to make a Metro 2.x
> client work with the service, it just can be the CXF one which seems to
> have none of these problems.
>
> FWIW when in a (webapp) context, where would META-INF/cxf/.. have to be?
> By now META-INF is on the same level as WEB-INF, I suspect this should do?
>
No, I don't think so. The "META-INF" is in the "root" of each entry in
the classpath. For a web-app, along with all of the jars, the
WEB-INF/classes is on the classpath, so you need
WEB-INF/classes/META-INF. Of course, you should be able to put the
resources in a jar as well, in which case they go in the META-INF in the
jar.
David
> TIA and all the best,
> Kristian
Re: CXF client in (glassfish) app server: dump SOAP messages?
Posted by Kristian Rink <ka...@googlemail.com>.
Am 26.03.2012 22:01, schrieb David Mansfield:
> Is it possible that you're not using CXF because glassfish is loading
> the RI (metro)? I had read some things on stackoverflow pointing to the
> necessity of putting some libraries into the endorsed dir to get
> glassfish to use cxf. This is all a vague handwave though, I can't
> remember the details.
Yes I have been through this round as well by now; initially I intended
to use Metro after all but it seems to be in no way whatsoever willing
to work with this service whereas CXF does way better. I had to mess
with the application classloader to make sure CXF is being seen/used indeed.
> Do you have any specific log messages or stack traces that definitely
> confirm that the CXF stack is being used?
Yes; in case of any issues I regularly end up with messages just like this
[...]
has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: Error reading XMLStreamReader.
[...]
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected
character 's' (code 115) in prolog; expected '<'
at [row,col {unknown-source}]: [1,39]
at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:639)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2032)
at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1117)
at
com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1140)
at
org.apache.cxf.binding.soap.interceptor.ReadHeadersInterceptor.handleMessage(ReadHeadersInterceptor.java:138)
... 99 more
|#]
[...]
... which at least _seems_ CXF to me - the Metro traces look a bit
different. And as I generally and totally fail to make a Metro 2.x
client work with the service, it just can be the CXF one which seems to
have none of these problems.
FWIW when in a (webapp) context, where would META-INF/cxf/.. have to be?
By now META-INF is on the same level as WEB-INF, I suspect this should do?
TIA and all the best,
Kristian
Re: CXF client in (glassfish) app server: dump SOAP messages?
Posted by David Mansfield <cx...@dm.cobite.com>.
On 03/26/2012 03:31 PM, Kristian Rink wrote:
> Hi David;
>
> Am 26.03.2012 21:10, schrieb David Karlsen:
>> Try this: http://cxf.apache.org/docs/debugging-and-logging.html
> Already made my way through that and tried most of the things on this
> list without much success. The programmatic client example doesn't seem
> to do anything (logging output after is the same as before), same for
> using Log4j or Slf4j - it works the same way it did before, no
> additional output is being dumped. Assuming HTTPS, I so far wanted to
> keep myself from debugging things on TCP/packet level as I thought there
> would be a straightforward way of making the client classes dump their
> messages recieved / sent.
Is it possible that you're not using CXF because glassfish is loading
the RI (metro)? I had read some things on stackoverflow pointing to the
necessity of putting some libraries into the endorsed dir to get
glassfish to use cxf. This is all a vague handwave though, I can't
remember the details.
Do you have any specific log messages or stack traces that definitely
confirm that the CXF stack is being used?
David
Re: CXF client in (glassfish) app server: dump SOAP messages?
Posted by Kristian Rink <ka...@googlemail.com>.
Hi David;
Am 26.03.2012 21:10, schrieb David Karlsen:
> Try this: http://cxf.apache.org/docs/debugging-and-logging.html
Already made my way through that and tried most of the things on this
list without much success. The programmatic client example doesn't seem
to do anything (logging output after is the same as before), same for
using Log4j or Slf4j - it works the same way it did before, no
additional output is being dumped. Assuming HTTPS, I so far wanted to
keep myself from debugging things on TCP/packet level as I thought there
would be a straightforward way of making the client classes dump their
messages recieved / sent.
TIA and all the best,
Kristian
Re: CXF client in (glassfish) app server: dump SOAP messages?
Posted by David Karlsen <da...@gmail.com>.
Try this: http://cxf.apache.org/docs/debugging-and-logging.html
2012/3/26 Kristian Rink <ka...@googlemail.com>:
> Folks;
>
> I'm trying to get an Apache CXF (2.4.6) client to work with a web service
> provided by one of our partners and, so far, fail. I am not really sure why
> it fails, I only see that the web service in some error situations doesn't
> return SOAP Faults but rather plaintext messages which is a _rather_ helpful
> thing yet unfortunately something I can't quickly fix.
>
> However, I'm by now trying to figure out how to make CXF simply dump all of
> its SOAP request and response messages for the sake of seeing what happened.
> The client runs inside an application context in a Glassfish v3.1 server and
> works well in most situations already. Concerning Logging, however, I feel a
> bit lost. So far I already tried virtually everything I could figure out by
> reading documentation, including
>
> ... adding various -D<whatever> options to my Glassfish <jvm-options> in
> order to do as I intend to do,
>
> ... removing most of the logging configuration in the application context
> (which natively uses slf4j and logback), and
>
> ... using the META-INF/cxf/org.apache.cxf.Logger file, both for slf4j or for
> log4j.
>
> Logback is configured by now to log virtually everything to STDOUT so the
> messages should appear where everything else appears, too (in the Glassfish
> server.log), yet - they don't. Spent most of the afternoon trying, yet still
> I fail making the CXF output anything more verbose than INFO statements. And
> I feel like giving up at the moment. Is there anything essential I am
> missing here? Any hints, no matter which, are greatly appreciated.
>
> Thanks for your time and all the best,
> Kristian
--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen