On Jul 23, 2008, at 7:24 AM, [EMAIL PROTECTED] wrote:
Hi Kevin, Lin, Daniel, Glen,
@Daniel: Your VM-Parameters solved this problem. Thank you very much
for
your help.
Yea, but it definitely shouldn't have been necessary.
@Glen: Thank you very much for your tipp, we will wait for Geronimo
2.1.2
and then we have Apache CXF2.0.6...
Actually, CXF 2.0.8. :-)
@All: Now I have two new issues ;-)
1) The client is written like described in
http://cwiki.apache.org/CXF20DOC/ws-security.html. For the server
part -
because of JavaEE5 - we choose
http://depressedprogrammer.wordpress.com/2007/07/31/cxf-ws-security-using-jsr-181-interceptor-annotations-xfire-migration/
.
In the first run I added
@InInterceptors
(interceptors={ "de.myapp.WSSecurityInterceptor" }) to
the WS-Implementation-Class and nothing happend. Afterwards I had a
try
with the interface class and added the same
@InInterceptors(interceptors={ "de.myapp.WSSecurityInterceptor" }).
After this changed the class de.myapp.WSSecurityInterceptor was
accessed.
Why do I have to add @... in implementation AND interface?
Not sure on that. Feel free to log a CXF bug. It should be
possible to just put it on the implementation. The interface should
be shareable between clients/servers and having interceptors defined
on it that should just be there for the server is not a good thing.
2) In the handleMessage(Message message) I receive after:
...
props.put(WSHandlerConstants.PASSWORD_TYPE,
WSConstants.PW_TEXT);
props.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ServerPasswordCallback.class.getName());
WSS4JInInterceptor wss4jInHandler = new
WSS4JInInterceptor(props);
...
.........................
Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:
661)
at
com.ctc.wstx.sr.BasicStreamReader.handleEOF(BasicStreamReader.java:
2134)
at
With CXF 2.0.2, that stack could result from a BUNCH of things. We
actually would get that stack if the server sent back and html error
page without setting a 404 or similar. Several things can cause
it. If you can tcpdump or wireshark the wire transfers to see what's
going on, that would be helpful. Good news is that this changed in
2.0.5 to get a better error message. :-)
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
