Hi Daniel,
I will do my best with the tcpmonitor. At the moment I try to put the
monitor in between client and server.
In EJB2.1 I knew how to do this, but in JavaEE5 and EJB3 everything is
generated.
I want to:
WSClient (8079) -> (8079)TCPMonitor(8080) -> WSService (8080)
My Code is:
...
URL wsdlLocation = new URL(serviceEndpointAdress +
"/" + name + "?wsdl");
QName serviceNameQ = new QName(nameSpace,
serviceName);
// dynamic service usage
Service service = Service.create(wsdlLocation,
serviceNameQ);
MyWS firstPort = service.getPort(MyWS.class);
firstPort.startMyMethod();
...
My Problem ist firstPort got already the information that physical port is
8080. This information is derived from the generated WSDL. How can I
change the port to 8079?
I have only one idea with a stored and modified WSDL in my head. But I
want to avoid this, there must be a better solution...
-Josef
Daniel Kulp <[EMAIL PROTECTED]>
23.07.2008 14:42
Bitte antworten an
[email protected]
An
[email protected]
Kopie
[EMAIL PROTECTED]
Thema
Re: Antwort: Re: WS-Stack Apache CXF asks for Axis2-Classes
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
BGS Beratungsgesellschaft
Software Systemplanung AG Niederlassung Rhein/Main
Robert-Koch-Straße 41
55129 Mainz
Fon: +49 (0) 6131 / 914-0
Fax: +49 (0) 6131 / 914-400
www.bgs-ag.de Geschäftssitz Mainz
Registergericht
Amtsgericht Mainz
HRB 62 50
Aufsichtsratsvorsitzender
Klaus Hellwig
Vorstand
Hanspeter Gau
Hermann Kiefer
Nils Manegold
