You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@xml.apache.org by ah...@intermediate.de on 2001/05/08 14:04:55 UTC
WSDL Toolkits
Hi all,
Does anyone use any other WSDL toolkit (for a Java proxy creation) than
IBM's?
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by fractals <fr...@ping.be>.
I tried GLUE (did the tutorial). It's a very nice API, fast, and above all,
very well documented.
www.themindelectric.com
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by fractals <fr...@ping.be>.
I tried GLUE (did the tutorial). It's a very nice API, fast, and above all,
very well documented.
www.themindelectric.com
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by Collin Goredema <co...@bellsouth.net>.
I didn't run any comparisons; I would venture to say they are equal in terms
of functionality.
----- Original Message -----
From: "David Wall" <dw...@Yozons.com>
To: <so...@xml.apache.org>
Sent: Tuesday, May 08, 2001 12:16 PM
Subject: Re: WSDL Toolkits
> > Try GLUE from http://www.themindelectric.com
>
> Is their SOAP 1.1 toolkit better or worse than the Apache one?
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
HTTPUtils.buildSocket broken for proxy over SSL
Posted by David Wall <dw...@Yozons.com>.
It appears that SOAP 2.2 will attempt to connect via SSL to the proxy server host and port from the "get go." My understanding is that a regular HTTP connection needs to be opened first, with a connect command specifying the real host/port to communicate with, and then followed by an SSL session that is then tunneled by the proxy server. This makes sense since the proxy server would not be able to understand the SSL connection otherwise, so it could not forward it to the real host outside the proxy.
I'm not sure how to fix the code, but since JSSE already supports proxies with the use of properties https.proxyHost and https.proxyPort, it makes sense that these perhaps could be used in conjunction with the proxy settings built into SOAPHTTPConnection. Does anybody know if that should work, or is the problem more severe? The idea would be for https proxying, those two properties would be set before calling the SSLUtils.buildSSLSocket so that JSSE would perhaps "do the right thing." Thoughts?
Thanks,
David
JAXM
Posted by David Wall <dw...@Yozons.com>.
Will Apache SOAP evolve to suport JAXM when it's ready? Or will that be left to Axis?
David
JAXM
Posted by David Wall <dw...@Yozons.com>.
Will Apache SOAP evolve to suport JAXM when it's ready? Or will that be left to Axis?
David
BUG FIX - Soap 2.2 SSL via proxy
Posted by David Wall <dw...@Yozons.com>.
How do I post code that seems to fix a bug in Apache SOAP 2.2 with respect to using SSL through a proxy server?
While I don't purport to be an Apache SOAP programming expert, I'll share the code here in the hopes that it will make it into the next iteration. Of course, I'm sure it can be made nicer since I was just trying to hack out a fix to keep me moving forward. There's no doubt a more elegant way... For now, I'm just using my modified JAR, but I'd much prefer to have the "blessed version" in the next release.
Thanks,
David
+++
In org.apache.soap.util.net.HTTPUtils (note that I've just branch the code -- again -- based on whether a proxy server was specified or not, so that if a proxy was specified, then it is passed along to the SSLUtils code)
private static Socket buildSocket(URL url, int targetPort,
String httpProxyHost, int httpProxyPort)
throws Exception {
Socket s = null;
String host = null;
int port;
if (httpProxyHost == null) {
host = url.getHost();
port = targetPort;
} else {
host = httpProxyHost;
port = httpProxyPort;
}
if (url.getProtocol().equalsIgnoreCase("HTTPS")) {
if ( httpProxyHost == null )
{
// Using reflection to avoid compile time dependencies
Class SSLUtilsClass =
Class.forName("org.apache.soap.util.net.SSLUtils");
Class[] paramTypes = new Class[] {String.class, int.class};
Method buildSSLSocket = SSLUtilsClass.getMethod(
"buildSSLSocket", paramTypes);
Object[] params = new Object[] {host, new Integer(port)};
s = (Socket)buildSSLSocket.invoke(null, params);
}
else
{
// Using reflection to avoid compile time dependencies
Class SSLUtilsClass =
Class.forName("org.apache.soap.util.net.SSLUtils");
Class[] paramTypes = new Class[] {String.class, int.class, String.class, int.class};
Method buildSSLSocket = SSLUtilsClass.getMethod(
"buildSSLSocket", paramTypes);
Object[] params = new Object[] {host, new Integer(port), url.getHost(), new Integer(targetPort)};
s = (Socket)buildSSLSocket.invoke(null, params);
}
} else {
s = new Socket(host, port);
}
return s;
}
+++
The new method added to org.apache.soap.util.net.SSLUtils differs because it it includes the parameters to the target host/port as well as the proxy host/port. It creates a normal socket, does the proxy tunnel handshake with a CONNECT statement, then wraps that socket in an SSL socket and returns that. Note that 'doTunnelHandshake()' was taken nearly "as is" from the sample code provided by Sun with JSSE 1.0.2.
/** This method builds an SSL socket through a tunnel proxy, after auto-starting SSL */
public static Socket buildSSLSocket(String proxyHost, int proxyPort, String targetHost, int targetPort)
throws IOException, UnknownHostException
{
/*
* Let's setup the SSLContext first, as there's a lot of
* computations to be done. If the socket were created
* before the SSLContext, the server/proxy might timeout
* waiting for the client to actually send something.
*/
SSLSocketFactory factory =
(SSLSocketFactory)SSLSocketFactory.getDefault();
Socket tunnel = new Socket(proxyHost, proxyPort);
doTunnelHandshake(tunnel, targetHost, targetPort);
/*
* Ok, let's overlay the tunnel socket with SSL.
*/
SSLSocket sslSocket =
(SSLSocket)factory.createSocket(tunnel, proxyHost, proxyPort, true);
/*
* Handshaking is started manually in this example because
* PrintWriter catches all IOExceptions (including
* SSLExceptions), sets an internal error flag, and then
* returns without rethrowing the exception.
*
* Unfortunately, this means any error messages are lost,
* which caused lots of confusion for others using this
* code. The only way to tell there was an error is to call
* PrintWriter.checkError().
*/
sslSocket.startHandshake();
return sslSocket;
}
/*
* Tell our tunnel where we want to CONNECT, and look for the
* right reply. Throw IOException if anything goes wrong.
*/
private static void doTunnelHandshake(Socket tunnel, String host, int port)
throws IOException
{
OutputStream out = tunnel.getOutputStream();
String msg = "CONNECT " + host + ":" + port + " HTTP/1.0\n"
+ "User-Agent: "
+ sun.net.www.protocol.http.HttpURLConnection.userAgent
+ "\r\n\r\n";
byte b[];
try {
/*
* We really do want ASCII7 -- the http protocol doesn't change
* with locale.
*/
b = msg.getBytes("ASCII7");
} catch (UnsupportedEncodingException ignored) {
/*
* If ASCII7 isn't there, something serious is wrong, but
* Paranoia Is Good (tm)
*/
b = msg.getBytes();
}
out.write(b);
out.flush();
/*
* We need to store the reply so we can create a detailed
* error message to the user.
*/
byte reply[] = new byte[200];
int replyLen = 0;
int newlinesSeen = 0;
boolean headerDone = false; /* Done on first newline */
InputStream in = tunnel.getInputStream();
boolean error = false;
while (newlinesSeen < 2) {
int i = in.read();
if (i < 0) {
throw new IOException("Unexpected EOF from proxy");
}
if (i == '\n') {
headerDone = true;
++newlinesSeen;
} else if (i != '\r') {
newlinesSeen = 0;
if (!headerDone && replyLen < reply.length) {
reply[replyLen++] = (byte) i;
}
}
}
/*
* Converting the byte array to a string is slightly wasteful
* in the case where the connection was successful, but it's
* insignificant compared to the network overhead.
*/
String replyStr;
try {
replyStr = new String(reply, 0, replyLen, "ASCII7");
} catch (UnsupportedEncodingException ignored) {
replyStr = new String(reply, 0, replyLen);
}
/* We asked for HTTP/1.0, so we should get that back */
if (!replyStr.startsWith("HTTP/1.0 200")) {
throw new IOException("Unable to tunnel through "
+ "proxy returns \"" + replyStr + "\"");
}
/* tunneling Handshake was successful! */
}
HTTPUtils.buildSocket broken for proxy over SSL
Posted by David Wall <dw...@Yozons.com>.
It appears that SOAP 2.2 will attempt to connect via SSL to the proxy server host and port from the "get go." My understanding is that a regular HTTP connection needs to be opened first, with a connect command specifying the real host/port to communicate with, and then followed by an SSL session that is then tunneled by the proxy server. This makes sense since the proxy server would not be able to understand the SSL connection otherwise, so it could not forward it to the real host outside the proxy.
I'm not sure how to fix the code, but since JSSE already supports proxies with the use of properties https.proxyHost and https.proxyPort, it makes sense that these perhaps could be used in conjunction with the proxy settings built into SOAPHTTPConnection. Does anybody know if that should work, or is the problem more severe? The idea would be for https proxying, those two properties would be set before calling the SSLUtils.buildSSLSocket so that JSSE would perhaps "do the right thing." Thoughts?
Thanks,
David
BUG FIX - Soap 2.2 SSL via proxy
Posted by David Wall <dw...@Yozons.com>.
How do I post code that seems to fix a bug in Apache SOAP 2.2 with respect to using SSL through a proxy server?
While I don't purport to be an Apache SOAP programming expert, I'll share the code here in the hopes that it will make it into the next iteration. Of course, I'm sure it can be made nicer since I was just trying to hack out a fix to keep me moving forward. There's no doubt a more elegant way... For now, I'm just using my modified JAR, but I'd much prefer to have the "blessed version" in the next release.
Thanks,
David
+++
In org.apache.soap.util.net.HTTPUtils (note that I've just branch the code -- again -- based on whether a proxy server was specified or not, so that if a proxy was specified, then it is passed along to the SSLUtils code)
private static Socket buildSocket(URL url, int targetPort,
String httpProxyHost, int httpProxyPort)
throws Exception {
Socket s = null;
String host = null;
int port;
if (httpProxyHost == null) {
host = url.getHost();
port = targetPort;
} else {
host = httpProxyHost;
port = httpProxyPort;
}
if (url.getProtocol().equalsIgnoreCase("HTTPS")) {
if ( httpProxyHost == null )
{
// Using reflection to avoid compile time dependencies
Class SSLUtilsClass =
Class.forName("org.apache.soap.util.net.SSLUtils");
Class[] paramTypes = new Class[] {String.class, int.class};
Method buildSSLSocket = SSLUtilsClass.getMethod(
"buildSSLSocket", paramTypes);
Object[] params = new Object[] {host, new Integer(port)};
s = (Socket)buildSSLSocket.invoke(null, params);
}
else
{
// Using reflection to avoid compile time dependencies
Class SSLUtilsClass =
Class.forName("org.apache.soap.util.net.SSLUtils");
Class[] paramTypes = new Class[] {String.class, int.class, String.class, int.class};
Method buildSSLSocket = SSLUtilsClass.getMethod(
"buildSSLSocket", paramTypes);
Object[] params = new Object[] {host, new Integer(port), url.getHost(), new Integer(targetPort)};
s = (Socket)buildSSLSocket.invoke(null, params);
}
} else {
s = new Socket(host, port);
}
return s;
}
+++
The new method added to org.apache.soap.util.net.SSLUtils differs because it it includes the parameters to the target host/port as well as the proxy host/port. It creates a normal socket, does the proxy tunnel handshake with a CONNECT statement, then wraps that socket in an SSL socket and returns that. Note that 'doTunnelHandshake()' was taken nearly "as is" from the sample code provided by Sun with JSSE 1.0.2.
/** This method builds an SSL socket through a tunnel proxy, after auto-starting SSL */
public static Socket buildSSLSocket(String proxyHost, int proxyPort, String targetHost, int targetPort)
throws IOException, UnknownHostException
{
/*
* Let's setup the SSLContext first, as there's a lot of
* computations to be done. If the socket were created
* before the SSLContext, the server/proxy might timeout
* waiting for the client to actually send something.
*/
SSLSocketFactory factory =
(SSLSocketFactory)SSLSocketFactory.getDefault();
Socket tunnel = new Socket(proxyHost, proxyPort);
doTunnelHandshake(tunnel, targetHost, targetPort);
/*
* Ok, let's overlay the tunnel socket with SSL.
*/
SSLSocket sslSocket =
(SSLSocket)factory.createSocket(tunnel, proxyHost, proxyPort, true);
/*
* Handshaking is started manually in this example because
* PrintWriter catches all IOExceptions (including
* SSLExceptions), sets an internal error flag, and then
* returns without rethrowing the exception.
*
* Unfortunately, this means any error messages are lost,
* which caused lots of confusion for others using this
* code. The only way to tell there was an error is to call
* PrintWriter.checkError().
*/
sslSocket.startHandshake();
return sslSocket;
}
/*
* Tell our tunnel where we want to CONNECT, and look for the
* right reply. Throw IOException if anything goes wrong.
*/
private static void doTunnelHandshake(Socket tunnel, String host, int port)
throws IOException
{
OutputStream out = tunnel.getOutputStream();
String msg = "CONNECT " + host + ":" + port + " HTTP/1.0\n"
+ "User-Agent: "
+ sun.net.www.protocol.http.HttpURLConnection.userAgent
+ "\r\n\r\n";
byte b[];
try {
/*
* We really do want ASCII7 -- the http protocol doesn't change
* with locale.
*/
b = msg.getBytes("ASCII7");
} catch (UnsupportedEncodingException ignored) {
/*
* If ASCII7 isn't there, something serious is wrong, but
* Paranoia Is Good (tm)
*/
b = msg.getBytes();
}
out.write(b);
out.flush();
/*
* We need to store the reply so we can create a detailed
* error message to the user.
*/
byte reply[] = new byte[200];
int replyLen = 0;
int newlinesSeen = 0;
boolean headerDone = false; /* Done on first newline */
InputStream in = tunnel.getInputStream();
boolean error = false;
while (newlinesSeen < 2) {
int i = in.read();
if (i < 0) {
throw new IOException("Unexpected EOF from proxy");
}
if (i == '\n') {
headerDone = true;
++newlinesSeen;
} else if (i != '\r') {
newlinesSeen = 0;
if (!headerDone && replyLen < reply.length) {
reply[replyLen++] = (byte) i;
}
}
}
/*
* Converting the byte array to a string is slightly wasteful
* in the case where the connection was successful, but it's
* insignificant compared to the network overhead.
*/
String replyStr;
try {
replyStr = new String(reply, 0, replyLen, "ASCII7");
} catch (UnsupportedEncodingException ignored) {
replyStr = new String(reply, 0, replyLen);
}
/* We asked for HTTP/1.0, so we should get that back */
if (!replyStr.startsWith("HTTP/1.0 200")) {
throw new IOException("Unable to tunnel through "
+ "proxy returns \"" + replyStr + "\"");
}
/* tunneling Handshake was successful! */
}
Re: WSDL Toolkits
Posted by Mike Sick <mi...@usermagnet.com>.
I use GLUE and think it rocks. It's fast, easy to setup, and has no messy
stubs and proxies to manage.
Mike Sick
----- Original Message -----
From: "David Wall" <dw...@Yozons.com>
To: <so...@xml.apache.org>
Sent: Tuesday, May 08, 2001 12:16 PM
Subject: Re: WSDL Toolkits
> > Try GLUE from http://www.themindelectric.com
>
> Is their SOAP 1.1 toolkit better or worse than the Apache one?
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by Mike Sick <mi...@usermagnet.com>.
I use GLUE and think it rocks. It's fast, easy to setup, and has no messy
stubs and proxies to manage.
Mike Sick
----- Original Message -----
From: "David Wall" <dw...@Yozons.com>
To: <so...@xml.apache.org>
Sent: Tuesday, May 08, 2001 12:16 PM
Subject: Re: WSDL Toolkits
> > Try GLUE from http://www.themindelectric.com
>
> Is their SOAP 1.1 toolkit better or worse than the Apache one?
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by Collin Goredema <co...@bellsouth.net>.
I didn't run any comparisons; I would venture to say they are equal in terms
of functionality.
----- Original Message -----
From: "David Wall" <dw...@Yozons.com>
To: <so...@xml.apache.org>
Sent: Tuesday, May 08, 2001 12:16 PM
Subject: Re: WSDL Toolkits
> > Try GLUE from http://www.themindelectric.com
>
> Is their SOAP 1.1 toolkit better or worse than the Apache one?
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by David Wall <dw...@Yozons.com>.
> Try GLUE from http://www.themindelectric.com
Is their SOAP 1.1 toolkit better or worse than the Apache one?
David
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by David Wall <dw...@Yozons.com>.
> Try GLUE from http://www.themindelectric.com
Is their SOAP 1.1 toolkit better or worse than the Apache one?
David
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by Collin Goredema <co...@bellsouth.net>.
Try GLUE from http://www.themindelectric.com
----- Original Message -----
From: <ah...@intermediate.de>
To: <so...@xml.apache.org>
Sent: Tuesday, May 08, 2001 8:04 AM
Subject: WSDL Toolkits
> Hi all,
>
> Does anyone use any other WSDL toolkit (for a Java proxy creation) than
> IBM's?
>
> Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: WSDL Toolkits
Posted by Collin Goredema <co...@bellsouth.net>.
Try GLUE from http://www.themindelectric.com
----- Original Message -----
From: <ah...@intermediate.de>
To: <so...@xml.apache.org>
Sent: Tuesday, May 08, 2001 8:04 AM
Subject: WSDL Toolkits
> Hi all,
>
> Does anyone use any other WSDL toolkit (for a Java proxy creation) than
> IBM's?
>
> Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
> For additional commands, email: soap-user-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org