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
