I solved the problem with the redirect in the meantime.
According to the RFC a redirect 302 should be answered with the same response
as the original request, i.e. a POST with a POST. For historical reasons the
standard JDK implementation of the JDK answers a POST with a GET.
There is a system
Hi Ron
Thank you for your response
anonymous wrote : 1. The problem in JBWS-1141 comes from the fact that Remoting
versions 2.x require a call to org.jboss.remoting.Client.connect() before any
calls to Client.invoke(), whereas earlier versions of Remoting didn't impose
that requirement. The
Hi Rino
Are you still having problems with this issue? If so, I can tell you a couple
of things that might help.
1. The problem in JBWS-1141 comes from the fact that Remoting versions 2.x
require a call to org.jboss.remoting.Client.connect() before any calls to
Client.invoke(), whereas
I did some more investigation in the meantime.
The exception with the JBoss Remoting 2.2.0 version was caused by the fact that
it tried to access a trust store that was not existing. Through the parameter
org.jboss.remoting.serverAuthMode one should be able to set from the outside
that server
It should be possible (according to the documentation) to pass in the client
cofiguration through a URL parameter. However this results in an exception when
starting up the server
Caused by: java.io.IOException: Error initializing server socket factory SSL
context: Can not find keystore url.
