Axis 1.4 - CommonsHTTPSender and proxy protocol problem
Hello all,
This is with Axis 1.4 and commons-httpclient 3.0.1
I have an axis client, deployed via webstart, which has been fine in the past
with picking up its proxy settings from the browser and communicating correctly.
Recently, I ran into a deployment at a customer site where the communication
was failing with a NullPointerException coming out of
...axis.transport.http.CommonsHTTPSender.invoke.
I put some simple prints into the source around that area and rebuilt the axis
jar to try and get a bit more information. I have included a snip of the logs
below and a section of the code I modified as well, however the end result is
that while it is reading the proxy host correctly, for some reason there ends
up being no protocol. This is an issue because the code expects there to be one
set.
I also placed prints in the getHostConfiguration method, which is called before
the failure, and it appears from that block of code that in the case where a
proxy is set, the host and port do not get set on the HostConfiguration object.
This would be why the null pointer ends up throwing an exception when the axis
CommonsHTTPSender attempts to test if the protocol is secure.
Has anyone seen an issue like this before? Is there something I am doing wrong
fundamentally, or something incorrect about the data that is being passed in?
Any thoughts or ideas would be greatly appreciated.
Thanks in advance,
Mario-
Log snip:
AXIS-MMF targetURL is https://mywebserviceurl
AXIS-MMF port is -1
AXIS-MMF hostInNonProxyList is false
AXIS-MMF hostConfiguration is HostConfiguration[proxyHost=http://proxy.customer]
AXIS-MMF hostConfiguration protocol is null
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.lang.NullPointerException
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:java.lang.NullPointerException
at
org.apache.axis.transport.http.CommonsHTTPSender.invoke(CommonsHTTPSender.java:193)
at
org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.client.AxisClient.invoke(AxisClient.java:165)
at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
at org.apache.axis.client.Call.invoke(Call.java:2767)
Code snip: Lines 185 to 197 --- 193 is the
hostConfiguration.getProtocol().isSecure() line.
if (msgContext.getMaintainSession()) {
HttpState state = httpClient.getState();
method.getParams().setCookiePolicy(CookiePolicy.BROWSER_COMPATIBILITY);
String host = hostConfiguration.getHost();
String path = targetURL.getPath();
//MMF
System.out.println(AXIS-MMF hostConfiguration is
+hostConfiguration);
System.out.println(AXIS-MMF hostConfiguration protocol is
+hostConfiguration.getProtocol());
boolean secure = hostConfiguration.getProtocol().isSecure();
fillHeaders(msgContext, state, HTTPConstants.HEADER_COOKIE,
host, path, secure);
fillHeaders(msgContext, state, HTTPConstants.HEADER_COOKIE2,
host, path, secure);
httpClient.setState(state);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis 1.4 configuration to use HTTP/1.1
Hello Shadab! Sorry I was not able to reply to this until now. I was trying to set the configuration of the client-side transport to utilize CommonsHTTPSender via settings on the Call object. That was not working. Jeff had given me some alternatives to try, such as setting the properties on the client-side EngineConfiguration. Unfortunately, I have not had the chance to try that yet as another project took precedence. Hopefully I can try that out later today or tomorrow and get back to the list with my results. Were you able to make some progress on this front in a different direction? Thanks! Mario- - Original Message From: Shadab [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Wednesday, October 3, 2007 2:36:50 AM Subject: Axis 1.4 configuration to use HTTP/1.1 Hi All, Please let me know if there is any way to configure Axis1.4 such that it uses HTTP/1.1 instead of HTTP/1.0 The request from the soapclient (implemented using service stub) lands with Axis/1.4 which in turn by default presumably uses HTTP/1.0. Can't this be changed somehow using CommonsHTTPSender as pointed by mail thread of Mario/Jeff Axis 1.4 CommonsHTTPSender question Date Sep:20:2007 ? Mario/Jeff, Please let me know if you people have reached some solution and will that solution be helpful in the scenario I have told above... Thanks, Shadab -- View this message in context: http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.html#a13014221 Sent from the Axis - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis 1.4 configuration to use HTTP/1.1
Hello Jeff!
Thank you for the information. This seems similar conceptually to the direction
you were pointing me in earlier, correct? I'll give it a shot. You are correct,
the other issue I had was the 3 requests instead of one, however you may be
right that the issues were related. I'll make this change first and go from
there.
Thanks again for the help!
Mario-
- Original Message
From: Walker, Jeff [EMAIL PROTECTED]
To: axis-user@ws.apache.org
Sent: Monday, October 8, 2007 11:27:23 AM
Subject: RE: Axis 1.4 configuration to use HTTP/1.1
DIV {
MARGIN:0px;}
Hi Mario,
Shadab got his problem solved. (He
wanted to use HTTP 1.1 in Axis 1.4 and do it programmmatically on the
clientside). the solution he emailed to me
is:
Hi Jeff,
Thank you so much for all the
info..
I have succesfully implemented the second
alternative of using - CommonsHTTPSender as the Transport Sender of the axis
client, viz.,
BasicClientConfig basicClientConfig =
new BasicClientConfig();
SimpleChain simpleChain = new
SimpleChain();
simpleChain.addHandler(new
CommonsHTTPSender());
basicClientConfig.deployTransport(http,
simpleChain);
LogonService_Service logonService =
new
LogonService_ServiceLocator(basicClientConfig);
and in the server-config.wsdd I added
the
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender
Cheers,
Shadab
But your issue is the three requests,
where one is in http 1.0 and the other two are http 1.1.
Correct?
If so, I still
think you are registering two handlers (that use CommonsSender and hence
http 1.1) and the default HTTPSender is
called in the middle to send it using HTTP 1.0.
If that is also true, then the programmatic registering of the two handlers is
incorrect.
-jeff
From: Mario Felarca
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 08, 2007 11:56
AM
To: axis-user@ws.apache.org
Subject: Re: Axis 1.4
configuration to use HTTP/1.1
Hello
Shadab!
Sorry I was not able to reply to this until now. I was trying
to set the configuration of the client-side transport to utilize
CommonsHTTPSender via settings on the Call object. That was not working. Jeff
had given me some alternatives to try, such as setting the properties on the
client-side EngineConfiguration. Unfortunately, I have not had the chance to
try that yet as another project took precedence. Hopefully I can try that out
later today or tomorrow and get back to the list with my results.
Were
you able to make some progress on this front in a different
direction?
Thanks!
Mario-
-
Original Message
From: Shadab [EMAIL PROTECTED]
To:
axis-user@ws.apache.org
Sent: Wednesday, October 3, 2007 2:36:50
AM
Subject: Axis 1.4 configuration to use HTTP/1.1
Hi All,
Please let me know if there is any way to configure
Axis1.4 such that it
uses HTTP/1.1 instead of HTTP/1.0
The request
from the soapclient (implemented using service stub) lands with
Axis/1.4
which in turn by default presumably uses HTTP/1.0.
Can't this be
changed somehow using CommonsHTTPSender as pointed by mail
thread of
Mario/Jeff Axis 1.4 CommonsHTTPSender question Date
Sep:20:2007
?
Mario/Jeff,
Please let me know if you people have
reached some solution and will that
solution be helpful in the scenario I
have told above...
Thanks,
Shadab
--
View this message in
context:
http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.html#a13014221
Sent
from the Axis - User mailing list archive at
Nabble.com.
-
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
commands, e-mail:
[EMAIL PROTECTED]
Re: Axis 1.4 configuration to use HTTP/1.1
Hello again Jeff!
That did the trick. The configuration I was trying to set on the Call object
directly before was incorrect and was causing the multiple requests and the
incorrect transport of the actual call.
I appreciate the help with this, and thanks to Shadab as well!
Mario-
- Original Message
From: Walker, Jeff [EMAIL PROTECTED]
To: axis-user@ws.apache.org
Sent: Monday, October 8, 2007 11:27:23 AM
Subject: RE: Axis 1.4 configuration to use HTTP/1.1
DIV {
MARGIN:0px;}
Hi Mario,
Shadab got his problem solved. (He
wanted to use HTTP 1.1 in Axis 1.4 and do it programmmatically on the
clientside). the solution he emailed to me
is:
Hi Jeff,
Thank you so much for all the
info..
I have succesfully implemented the second
alternative of using - CommonsHTTPSender as the Transport Sender of the axis
client, viz.,
BasicClientConfig basicClientConfig =
new BasicClientConfig();
SimpleChain simpleChain = new
SimpleChain();
simpleChain.addHandler(new
CommonsHTTPSender());
basicClientConfig.deployTransport(http,
simpleChain);
LogonService_Service logonService =
new
LogonService_ServiceLocator(basicClientConfig);
and in the server-config.wsdd I added
the
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender
Cheers,
Shadab
But your issue is the three requests,
where one is in http 1.0 and the other two are http 1.1.
Correct?
If so, I still
think you are registering two handlers (that use CommonsSender and hence
http 1.1) and the default HTTPSender is
called in the middle to send it using HTTP 1.0.
If that is also true, then the programmatic registering of the two handlers is
incorrect.
-jeff
From: Mario Felarca
[mailto:[EMAIL PROTECTED]
Sent: Monday, October 08, 2007 11:56
AM
To: axis-user@ws.apache.org
Subject: Re: Axis 1.4
configuration to use HTTP/1.1
Hello
Shadab!
Sorry I was not able to reply to this until now. I was trying
to set the configuration of the client-side transport to utilize
CommonsHTTPSender via settings on the Call object. That was not working. Jeff
had given me some alternatives to try, such as setting the properties on the
client-side EngineConfiguration. Unfortunately, I have not had the chance to
try that yet as another project took precedence. Hopefully I can try that out
later today or tomorrow and get back to the list with my results.
Were
you able to make some progress on this front in a different
direction?
Thanks!
Mario-
-
Original Message
From: Shadab [EMAIL PROTECTED]
To:
axis-user@ws.apache.org
Sent: Wednesday, October 3, 2007 2:36:50
AM
Subject: Axis 1.4 configuration to use HTTP/1.1
Hi All,
Please let me know if there is any way to configure
Axis1.4 such that it
uses HTTP/1.1 instead of HTTP/1.0
The request
from the soapclient (implemented using service stub) lands with
Axis/1.4
which in turn by default presumably uses HTTP/1.0.
Can't this be
changed somehow using CommonsHTTPSender as pointed by mail
thread of
Mario/Jeff Axis 1.4 CommonsHTTPSender question Date
Sep:20:2007
?
Mario/Jeff,
Please let me know if you people have
reached some solution and will that
solution be helpful in the scenario I
have told above...
Thanks,
Shadab
--
View this message in
context:
http://www.nabble.com/Axis-1.4-configuration-to-use-HTTP-1.1-tf4560281.html#a13014221
Sent
from the Axis - User mailing list archive at
Nabble.com.
-
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
commands, e-mail:
[EMAIL PROTECTED]
Re: Axis 1.4 CommonsHTTPSender question
Ugh...once again, had some of the code eaten. Putting it back in under the
first Request: block.
Thanks,
Mario-
- Original Message
From: Mario Felarca [EMAIL PROTECTED]
To: axis-user@ws.apache.org
Sent: Thursday, September 20, 2007 11:22:03 AM
Subject: Re: Axis 1.4 CommonsHTTPSender question
Thanks for the feedback Jeff! That helps. I do have a follow up question for
you or anyone else in the group. Is the way I am setting the client to
programattically utilize CommonsHTTPSender for the transport correct? I believe
it is, or at least it has an effect, since without it, the connection works
fine. I have tried setting the chunked property to false with the following
code and it does not appear to be working:
Hashtable httpHeaders = new Hashtable();
httpHeaders.put(HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED, false);
_call.setProperty(HTTPConstants.REQUEST_HEADERS, httpHeaders);
Also, if it is
using CommonsHTTPSender, I should not have to set a property to get it to use
HTTP 1.1, correct? However, in the tcpmon output, for some reason the second
connection (which I still don't know where the second and third attempted
connections are coming from) clearly uses 1.0, while the other two use 1.1. Is
this an automatic retry under 1.0 if the 1.1 connection fails for some reason?
I have tried adding in the following line with no discernible effect.
httpHeaders.put(MessageContext.HTTP_TRANSPORT_VERSION,
HTTPConstants.HEADER_PROTOCOL_11);
I am including the output below from tcpmon for what is a SINGLE call to invoke
on my _call object. You can see it results in 3 connections, and for some
reason, it doesn't seem to be taking the headers. At the very bottom, I include
the output from the successful Request (not using CommonsHTTPSender) for
reference.
Thanks again in advance!
Mario-
From the
table:
StateTime Request Host Target
HostRequest
Done2007-09-20 10:48:34localhost127.0.0.1 POST
/axis/services/USERSERVICE HTTP/1.1
Done2007-09-20 10:48:36localhost127.0.0.1 POST
/axis/services/USERSERVICE HTTP/1.0
Done2007-09-20 10:48:36localhost127.0.0.1 POST
/axis/services/USERSERVICE HTTP/1.1
The Request and Response headers for each of the above, in
#1
Request:
POST /axis/services/USERSERVICE
HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction:
User-Agent: Axis/1.4
axis.transport.version: HTTP/1.1
Host: 127.0.0.1:
Content-Length: 1221
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Thu, 20 Sep 2007 15:48:35 GMT
Server: Apache-Coyote/1.1
Connection: close
#2
Request:
POST /axis/services/USERSERVICE HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.4
Host: 127.0.0.1:
Cache-Control: no-cache
Pragma: no-cache
SOAPAction:
Content-Length: 1221
axis.transport.version: HTTP/1.1
chunked: false
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml;charset=utf-8
Date: Thu, 20 Sep 2007 15:48:35 GMT
Server: Apache-Coyote/1.1
Connection:
close
#3
Request:
POST /axis/services/RGCIL HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction:
User-Agent: Axis/1.4
axis.transport.version: HTTP/1.1
Host: 127.0.0.1:
Content-Length: 1221
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Thu, 20 Sep 2007 15:48:35 GMT
Server: Apache-Coyote/1.1
Connection: close
The contents of each Request and Response are the same except for the fact that
in the POST HTTP 1.0 version, the chunked string information you talked about
is not present in the response. So I am only posting each one once.
Request:
Response:
1339
soapenv:Server.userException org.xml.sax.SAXException: No deserializer for
{http://schemas.xmlsoap.org/soap/encoding/}string
org.xml.sax.SAXException'http://xml.apache.org/axis/;org.xml.sax.SAXException:
No deserializer for {http://schemas.xmlsoap.org/soap/encoding/}string
at
org.apache.axis.encoding.DeserializerImpl.onStartElement(DeserializerImpl.java:453)
at
org.apache.axis.encoding.DeserializerImpl.startElement(DeserializerImpl.java:393)
at
org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1048)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165)
at
org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141)
at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236)
at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384)
at
org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:81)
at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323
Re: Axis 1.4 CommonsHTTPSender question
Once more...
- Original Message
From: Mario Felarca [EMAIL PROTECTED]
Ugh...once again, had some of the code eaten. Putting it back in under the
first Request: block.
Thanks,
Mario-
- Original Message
From: Mario Felarca [EMAIL PROTECTED]
Thanks for the feedback Jeff! That helps. I do have a follow up question for
you or anyone else in the group. Is the way I am setting the client to
programattically utilize CommonsHTTPSender for the
transport correct? I believe it is, or at least it has an effect, since
without it, the connection works fine. I have tried setting the chunked
property to false with the following code and it does not appear to be working:
Hashtable httpHeaders = new Hashtable();
httpHeaders.put(HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED, false);
_call.setProperty(HTTPConstants.REQUEST_HEADERS, httpHeaders);
Also, if it is
using CommonsHTTPSender, I should not have to set a property to get it to use
HTTP 1.1, correct? However, in the tcpmon output, for some reason the second
connection (which I still don't know where the second and third attempted
connections are coming from) clearly uses 1.0, while the other two use 1.1. Is
this an automatic retry under 1.0 if the 1.1 connection fails for some reason?
I have tried adding in the following line with no discernible effect.
httpHeaders.put(MessageContext.HTTP_TRANSPORT_VERSION,
HTTPConstants.HEADER_PROTOCOL_11);
I am including the output below from tcpmon for what is a SINGLE call to invoke
on my _call object. You can see it results in 3 connections, and for some
reason, it doesn't seem to be taking the headers. At the very bottom, I include
the output from the successful Request (not using CommonsHTTPSender) for
reference.
Thanks again in advance!
Mario-
From the
table:
StateTime Request Host Target
HostRequest
Done2007-09-20 10:48:34localhost127.0.0.1 POST
/axis/services/USERSERVICE HTTP/1.1
Done2007-09-20 10:48:36localhost127.0.0.1 POST
/axis/services/USERSERVICE HTTP/1.0
Done2007-09-20 10:48:36localhost127.0.0.1 POST
/axis/services/USERSERVICE HTTP/1.1
The Request and Response headers for each of the above, in
#1
Request:
POST /axis/services/USERSERVICE
HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction:
User-Agent: Axis/1.4
axis.transport.version: HTTP/1.1
Host: 127.0.0.1:
Content-Length: 1221
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Thu, 20 Sep 2007 15:48:35 GMT
Server: Apache-Coyote/1.1
Connection: close
#2
Request:
POST /axis/services/USERSERVICE HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.4
Host: 127.0.0.1:
Cache-Control: no-cache
Pragma: no-cache
SOAPAction:
Content-Length: 1221
axis.transport.version: HTTP/1.1
chunked: false
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml;charset=utf-8
Date: Thu, 20 Sep 2007 15:48:35 GMT
Server: Apache-Coyote/1.1
Connection:
close
#3
Request:
POST /axis/services/RGCIL HTTP/1.1
Content-Type: text/xml; charset=utf-8
SOAPAction:
User-Agent: Axis/1.4
axis.transport.version: HTTP/1.1
Host: 127.0.0.1:
Content-Length: 1221
Response:
HTTP/1.1 500 Internal Server Error
Content-Type: text/xml;charset=utf-8
Transfer-Encoding: chunked
Date: Thu, 20 Sep 2007 15:48:35 GMT
Server: Apache-Coyote/1.1
Connection: close
The contents of each Request and Response are the same except for the fact that
in the POST HTTP 1.0 version, the chunked string information you talked about
is not present in the response. So I am only posting each one once.
Request:
?xml version=1.0 encoding=UTF-8?soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;soapenv:BodyprocessMessage
xmlns=urn:USin0 soapenc:arrayType=xsd:anyType[1]
xsi:type=soapenc:Array
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;in0
xsi:type=soapenc:string![CDATA[SOMEUSERDATA]]/in0/in0/processMessage/soapenv:Body/soapenv:Envelope
Response:
1339
soapenv:Server.userException org.xml.sax.SAXException: No deserializer for
{http://schemas.xmlsoap.org/soap/encoding/}string
org.xml.sax.SAXException'http://xml.apache.org/axis/;org.xml.sax.SAXException:
No deserializer for {http://schemas.xmlsoap.org/soap/encoding/}string
at
org.apache.axis.encoding.DeserializerImpl.onStartElement(DeserializerImpl.java:453)
at
org.apache.axis.encoding.DeserializerImpl.startElement(DeserializerImpl.java:393)
at
org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1048)
at
org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165
Re: Axis 1.4 CommonsHTTPSender question
Thanks again Jeff. I am currently using/modifying the stub code that is
generated from the WSDL, so I was trying to only modify as little as necessary,
and that seemed to be setting properties and elements on the Call object.
I will try it out and look up other items that can be set within the
EngineConfiguration as well on the client side.
For the server side, it is being configured by the wsdd, is the transport
name=http pivot=java:org.apache.axis.transport.http.CommonsHTTPSender
/ block sufficient and correct?
Thanks!
M-
- Original Message
From: Walker, Jeff [EMAIL PROTECTED]
To: axis-user@ws.apache.org
Sent: Thursday, September 20, 2007 2:14:39 PM
Subject: RE: Axis 1.4 CommonsHTTPSender question
DIV {
MARGIN:0px;}
So,
you have a bunch of questions, and I have only a
suggestion, or two.
I'm not convinced the way you programmatically setup the
sender is correct. Perhaps your way is right (or almost right) but I would have
approached it like this:
...
EngineConfiguration defaultConfig = (new
DefaultEngineConfigurationFactory()).getClientEngineConfig();
SimpleProvider
config = new SimpleProvider(defaultConfig);
SimpleChain c = new
SimpleChain(new CommonsHTTPSender());
config.deployTransport(http,
c);
...
Service service = new Service(config);
Call call =
(Call)service.createCall();
...
then set the bewielding array of parameters on the
Call object. (This is why most people don't do dynamic clients, these
parameters
are too hard to get right). Now, I did not test the above code, so I
have no real idea if it is correct.
Yes, CommonHTTPSender seems to use 1.1 by default. Which makes me
think the two handlers you setup are in fact using CommonsHTTPSender (because
they sent their requests using 1.1) and the middle request was sent by the
default HTTPSender, which I suspect still uses HTTP
1.0.
-jeff
Now, since it is a
programmatically defined client, I activate the
CommonsHTTPSender by adding
the following lines to the client:
CommonsHTTPSender reqHandler = new
CommonsHTTPSender();
CommonsHTTPSender respHandler = new
CommonsHTTPSender();
_call.setClientHandlers(reqHandler,
respHandler);
The following line is added to the
server-config.wsdd:
transport
name=http
pivot=java:org.apache.axis.transport.http.CommonsHTTPSender
/
From: Mario Felarca
[mailto:[EMAIL PROTECTED]
Sent: Thursday, September 20, 2007
1:09 PM
To: axis-user@ws.apache.org
Subject: Re: Axis 1.4
CommonsHTTPSender question
Once
more...
-
Original Message
From: Mario Felarca
[EMAIL PROTECTED]
Ugh...once
again, had some of the code eaten. Putting it back in under the first
Request:
block.
Thanks,
Mario-
-
Original Message
From: Mario Felarca
[EMAIL PROTECTED]
Thanks for the feedback Jeff! That helps. I do have a follow up question
for you or anyone else in the group. Is the way I am setting the client to
programattically utilize CommonsHTTPSender for the transport correct? I
believe it is, or at least it has an effect, since without it, the connection
works fine. I have tried setting the chunked property to false with the
following code and it does not appear to be
working:
Hashtable
httpHeaders = new Hashtable();
httpHeaders.put(HTTPConstants.HEADER_TRANSFER_ENCODING_CHUNKED,
false);
_call.setProperty(HTTPConstants.REQUEST_HEADERS, httpHeaders);
Also, if
it is using CommonsHTTPSender, I should not have to set a property to get it
to use HTTP 1.1, correct? However, in the tcpmon output, for some reason the
second connection (which I still don't know where the second and third
attempted connections are coming from) clearly uses 1.0, while the other two
use 1.1. Is this an automatic retry under 1.0 if the 1.1 connection fails for
some reason? I have tried adding in the following line with no discernible
effect.
httpHeaders.put(MessageContext.HTTP_TRANSPORT_VERSION,
HTTPConstants.HEADER_PROTOCOL_11);
I am including the output below from
tcpmon for what is a SINGLE call to invoke on my _call object. You can see it
results in 3 connections, and for some reason, it doesn't seem to be taking
the headers. At the very bottom, I include the output from the successful
Request (not using CommonsHTTPSender) for reference.
Thanks again in
advance!
Mario-
From the table:
State
Time
Request
HostTarget Host Request
Done
2007-09-20 10:48:34 localhost
127.0.0.1 POST
/axis/services/USERSERVICE HTTP/1.1
Done 2007-09-20 10:48:36
localhost
127.0.0.1 POST /axis/services/USERSERVICE
HTTP/1.0
Done 2007-09-20 10:48:36 localhost
127.0.0.1
POST /axis/services/USERSERVICE HTTP/1.1
The Request and Response
headers for each of the above, in
#1
Request
Re: Axis 1.4 CommonsHTTPSender question
Ah...to clarify my original post. Either I was a little too enthusiastic in editing the tcpmon data for brevity or it somehow got stripped out. Here is what I really meant to post with the more meaningful SOAP content. Thanks again! Mario- Before changing to use CommonsHTTPSender: POST /axis/services/USERSERVICE HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.4 Host: 127.0.0.1: Cache-Control: no-cache Pragma: no-cache SOAPAction: Content-Length: 1088 lt;?xml version=1.0 encoding=UTF-8?gt;lt;soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/;; xmlns:xsd=http://www.w3.org/2001/XMLSchema;; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instancegt;lt;soapenv:Bodygt;lt;processMessage xmlns=urn:RGgt;lt;in0 xsi:type=xsd:stringgt;lt;![CDATA[SOMEUSERDATA]]gt;lt;/in0gt;lt;/processMessagegt;lt;/soapenv:Bodygt;lt;/soapenv:Envelopegt; And now using CommonsHTTPSender: POST /axis/services/USERSERVICE HTTP/1.1 Content-Type: text/xml; charset=utf-8 SOAPAction: User-Agent: Axis/1.4 Host: 127.0.0.1: Transfer-Encoding: chunked 4c5 ?xml version=1.0 encoding=UTF-8?soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;soapenv:BodyprocessMessage xmlns=urn:RGin0 soapenc:arrayType=xsd:anyType[1] xsi:type=soapenc:Array xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;in0 xsi:type=soapenc:string![CDATA[SOMEUSERDATA]]/in0/in0/processMessage/soapenv:Body/soapenv:Envelope 0 - Original Message From: Mario Felarca [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Thursday, September 13, 2007 9:33:31 PM Subject: Axis 1.4 CommonsHTTPSender question Hello all! I have a client where before setting the client to use CommonsHTTPSender, it worked fine. The client would post using HTTP 1.0, and it would do so once only and everything was fine. Now, since it is a programmatically defined client, I activate the CommonsHTTPSender by adding the following lines to the client: CommonsHTTPSender reqHandler = new CommonsHTTPSender(); CommonsHTTPSender respHandler = new CommonsHTTPSender(); _call.setClientHandlers(reqHandler, respHandler); The following line is added to the server-config.wsdd: transport name=http pivot=java:org.apache.axis.transport.http.CommonsHTTPSender / The behavior I am seeing in tcpmon when NOT using CommonsHTTPSender is: POST /axis/services/USERSERVICE HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.4 Host: 127.0.0.1: Cache-Control: no-cache Pragma: no-cache SOAPAction: Content-Length: 1088 ![CDATA[SOMEUSERDATA]] The behavior I am seeing in tcpmon when I use CommonsHTTPSender is listed below, however it is also notable that it fires three times instead of once, all on its own. The first and third time are HTTP 1.1, and the middle one is HTTP 1.0. I'm not sure why this behavior exists as well. Additionally, there are these strings before and after the soap content, the string before is 4c5 and the string after is 0. I don't know where these come from either, and if these are the reasons for the 3 seperate calls. Anyway, the tcpmon is: POST /axis/services/USERSERVICE HTTP/1.1 Content-Type: text/xml; charset=utf-8 SOAPAction: User-Agent: Axis/1.4 Host: 127.0.0.1: Transfer-Encoding: chunked 4c5 ![CDATA[SOMEUSERDATA]] 0 Any help or guidance would be greatly appreciated!! Thanks in advance, Mario- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Axis 1.4 CommonsHTTPSender question
Hello all! I have a client where before setting the client to use CommonsHTTPSender, it worked fine. The client would post using HTTP 1.0, and it would do so once only and everything was fine. Now, since it is a programmatically defined client, I activate the CommonsHTTPSender by adding the following lines to the client: CommonsHTTPSender reqHandler = new CommonsHTTPSender(); CommonsHTTPSender respHandler = new CommonsHTTPSender(); _call.setClientHandlers(reqHandler, respHandler); The following line is added to the server-config.wsdd: transport name=http pivot=java:org.apache.axis.transport.http.CommonsHTTPSender / The behavior I am seeing in tcpmon when NOT using CommonsHTTPSender is: POST /axis/services/USERSERVICE HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, application/dime, multipart/related, text/* User-Agent: Axis/1.4 Host: 127.0.0.1: Cache-Control: no-cache Pragma: no-cache SOAPAction: Content-Length: 1088 ![CDATA[SOMEUSERDATA]] The behavior I am seeing in tcpmon when I use CommonsHTTPSender is listed below, however it is also notable that it fires three times instead of once, all on its own. The first and third time are HTTP 1.1, and the middle one is HTTP 1.0. I'm not sure why this behavior exists as well. Additionally, there are these strings before and after the soap content, the string before is 4c5 and the string after is 0. I don't know where these come from either, and if these are the reasons for the 3 seperate calls. Anyway, the tcpmon is: POST /axis/services/USERSERVICE HTTP/1.1 Content-Type: text/xml; charset=utf-8 SOAPAction: User-Agent: Axis/1.4 Host: 127.0.0.1: Transfer-Encoding: chunked 4c5 ![CDATA[SOMEUSERDATA]] 0 Any help or guidance would be greatly appreciated!! Thanks in advance, Mario- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Axis and HTTP Proxy question
Hello, I have a Java client running through Java 5.0 that is utilizing Axis to connect to an https endpoint. It appears that the Call object I am using builds up a direct socket connection (socket:// PROXY=DIRECT) to do this, even if I have specified an HTTP proxy that it should be using. If it is a SOCKS proxy, things seem to work fine as well. I have tried setting many different properties, both within my code and externally, that I have found on the list and on other sources on the web, but I fear that I am still missing some critical element that needs to be configured. Can someone point me in the right direction with regards to trying to get the connection to work with respect to HTTP proxies? Even a pointer to a good resource to dig in would be greatly appreciated as I seem to be out of places to search. Thanks much in advance! Mario- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Axis and HTTP Proxy question
Ok..a couple of additional questions and some interesting behavior. The first items is that I was trying to convert my endpoint into a URI, and when I did a super.cachedEndpoint.toURI() from within the Stub class, it actually fired a correct network connection, with https://host and proxy=HTTP @ proxyHost. Regarding the actual Call object itself, do I need to specify the Transport and the Handlers in order for it to recognize an HTTP proxy for an https endpoint? Or should that be configured or registered somewhere else already and the Call will automatically pick it up. I guess a final question would be if I need to do that registration somewhere. Thanks in advance again! Mario- - Original Message From: Mario Felarca [EMAIL PROTECTED] To: axis-user@ws.apache.org Sent: Thursday, March 1, 2007 4:55:27 PM Subject: Axis and HTTP Proxy question Hello, I have a Java client running through Java 5.0 that is utilizing Axis to connect to an https endpoint. It appears that the Call object I am using builds up a direct socket connection (socket:// PROXY=DIRECT) to do this, even if I have specified an HTTP proxy that it should be using. If it is a SOCKS proxy, things seem to work fine as well. I have tried setting many different properties, both within my code and externally, that I have found on the list and on other sources on the web, but I fear that I am still missing some critical element that needs to be configured. Can someone point me in the right direction with regards to trying to get the connection to work with respect to HTTP proxies? Even a pointer to a good resource to dig in would be greatly appreciated as I seem to be out of places to search. Thanks much in advance! Mario- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Quick 1.2 configuration and size question
Hello, We have been using Axis Java 1.2 for a while and it has worked out great. We are running it on Tomcat 4 and Java 5. We have not had the chance to upgrade yet, and we are looking to do so, however in the present, we have run into a situation where I am not sure what exactly the culprit is or where to start looking at configuration (web server, axis, soap) in order to fix it. The scenario is that our webservice is running in document/literal, and it returns a string. If the string reaches a certain length ( 200,000) it appears that the response is simply cut off. I have been using the axis tcp monitor to view this. I believe this is an overall response size issue, as even if I break the return into multiple entries in the returned object array, it still breaks in the same fashion. If there are any pointers or ideas, or if one can just point me in the correct direction, I would greatly appreciate it! Thanks much in advance, Mario- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pre-loading a service, or handing off a singleton?
Hello all, If I have a service that is APPLICATION scoped, is tehre a way for me to have axis load it upon startup, instead of when the first request comes in? Failing that, is there a way for me to hand a singelton of that service implementation off to axis instead of axis spinning up its own? That would be a work-around of sorts. Thanks in advance! Mario-
Re: Question about xsd:anyType arrays in doc/literal wrapped mode
Thank you very much for the clarification Anne! --- Anne Thomas Manes [EMAIL PROTECTED] wrote: An instance of an array may contain only one type, even if you define that type as anyType. Anne On 6/15/05, Mario Felarca [EMAIL PROTECTED] wrote: Hello, First I would like to say thank you to everyone that has contributed to this list. While I have lurked and been helped a lot by information here, I have not had a chance up until now to say thanks, so, thanks. :) My question has to deal with arrays. I have looked over the archives, and a lot of these questions come up, but I never saw a definitive answer (or I missed it). A lot of these questions came up around the encoded to doc/literal transition threads. Basically, if I have an array that I want to go over the wire, and that contents of that array can be anything, why is it that if the contents are (coming from the Java side of things) a String, a Boolean and an Integer, I get the Found character data inside an array element while deserializing exception. If the array is xsd:anyType, does that still constrain it to one type out of the any? If not, can someone point me in the direction that I probably need to look to figure out why this is? Thanks much in advance, Mario-
Question about xsd:anyType arrays in doc/literal wrapped mode
Hello, First I would like to say thank you to everyone that has contributed to this list. While I have lurked and been helped a lot by information here, I have not had a chance up until now to say thanks, so, thanks. :) My question has to deal with arrays. I have looked over the archives, and a lot of these questions come up, but I never saw a definitive answer (or I missed it). A lot of these questions came up around the encoded to doc/literal transition threads. Basically, if I have an array that I want to go over the wire, and that contents of that array can be anything, why is it that if the contents are (coming from the Java side of things) a String, a Boolean and an Integer, I get the Found character data inside an array element while deserializing exception. If the array is xsd:anyType, does that still constrain it to one type out of the any? If not, can someone point me in the direction that I probably need to look to figure out why this is? Thanks much in advance, Mario-
