You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "KUMAR,PANKAJ (HP-Cupertino,ex1)" <pa...@hp.com> on 2002/02/26 19:47:19 UTC
[C2.0.1]Problem with SOAP Logicsheet in accessing .Net Web Servic
es
Hi,
I observed some bizzare behaviour and thought might as well report it.
I have written a simple web-application consisting of an XSP file (
zipcode-info.xsp ) and an XSL stylesheet ( zipcode-info.xsl ) that accesses
two SOAP services at http://alethea.net:80/webservices/LocalTime.asmx and
http://www.vbws.com:80/services/weatherretriever.asmx ( I found these at
http://www.xmethods.org from .asmx, I guess they are .Net web services and
the HTTP server is IIS ) using the SOAP logicsheet. This application worked
fine from my office machine ( behind a firewall, so I had to specify http
proxy host and port ), but failed to work ( first, it threw an exception "-1
port out of range" and then when I explicitly specified port 80, it just
hung waiting for a response from the service ) from my home computer ( no
firewall ).
I should add that access to web services deployed under TomCat works fine (
as long as you explicitly specify port 80 for http ).
I looked into the code and figured out that the use of httpclient code (
from org.apache.commons.httpclient.* ) in file SOAPHelper.java is the
culprit. Replaced this file with another ( included in the mail ) that uses
the JDK classes for HTTP transport and everything worked fine.
Here are the files mentioned in this mail:
<<zipcode-info.xsl>> <<zipcode-info.xsp>> <<SOAPHelper.java>>
To run this application, you need to place zipcode-info.xsl and
zipcode-info.xsp at a suitable place within your cocoon deployment and have
a suitable entry in the sitemap file. In my setup, I have the XSP and XSL
files in docs\samples\xscript and following entry in the sitemap:
<map:match pattern="xscript/zipcode-info">
<map:generate type="serverpages"
src="docs/samples/xscript/zipcode-info.xsp"/>
<map:transform src="docs/samples/xscript/zipcode-info.xsl"/>
<map:transform src="stylesheets/dynamic-page2html.xsl">
<map:parameter name="view-source"
value="docs/samples/xscript/zipcode-info.xsp"/>
</map:transform>
<map:serialize/>
</map:match>
Note: This application currently "streams-in" the SOAP documents returned
from web-services to the main XML document and relies on the stylesheet to
pickup appropriate fields. A better approach is perhaps to use XScript. I am
still investigating/experimenting with this option.
/Pankaj.
Re: [C2.0.1]Problem with SOAP Logicsheet in accessing .Net Web Servic es
Posted by Davanum Srinivas <di...@yahoo.com>.
Pankaj,
Can you please add this as an entry in bugzilla? (http://nagoya.apache.org).
Also, did you figure out what problems are in org.apache.commons.httpclient.*? Can you send them a
patch? The only way the code will become better is when we keep an eye out for each others
mistakes and help correct them. Am sure jakarta-commons guys would appreciate a heads-up/patches
for problems with their code.
Thanks,
dims
--- "KUMAR,PANKAJ (HP-Cupertino,ex1)" <pa...@hp.com> wrote:
> Hi,
>
> I observed some bizzare behaviour and thought might as well report it.
>
> I have written a simple web-application consisting of an XSP file (
> zipcode-info.xsp ) and an XSL stylesheet ( zipcode-info.xsl ) that accesses
> two SOAP services at http://alethea.net:80/webservices/LocalTime.asmx and
> http://www.vbws.com:80/services/weatherretriever.asmx ( I found these at
> http://www.xmethods.org from .asmx, I guess they are .Net web services and
> the HTTP server is IIS ) using the SOAP logicsheet. This application worked
> fine from my office machine ( behind a firewall, so I had to specify http
> proxy host and port ), but failed to work ( first, it threw an exception "-1
> port out of range" and then when I explicitly specified port 80, it just
> hung waiting for a response from the service ) from my home computer ( no
> firewall ).
>
> I should add that access to web services deployed under TomCat works fine (
> as long as you explicitly specify port 80 for http ).
>
> I looked into the code and figured out that the use of httpclient code (
> from org.apache.commons.httpclient.* ) in file SOAPHelper.java is the
> culprit. Replaced this file with another ( included in the mail ) that uses
> the JDK classes for HTTP transport and everything worked fine.
>
> Here are the files mentioned in this mail:
> <<zipcode-info.xsl>> <<zipcode-info.xsp>> <<SOAPHelper.java>>
> To run this application, you need to place zipcode-info.xsl and
> zipcode-info.xsp at a suitable place within your cocoon deployment and have
> a suitable entry in the sitemap file. In my setup, I have the XSP and XSL
> files in docs\samples\xscript and following entry in the sitemap:
>
> <map:match pattern="xscript/zipcode-info">
> <map:generate type="serverpages"
> src="docs/samples/xscript/zipcode-info.xsp"/>
> <map:transform src="docs/samples/xscript/zipcode-info.xsl"/>
> <map:transform src="stylesheets/dynamic-page2html.xsl">
> <map:parameter name="view-source"
> value="docs/samples/xscript/zipcode-info.xsp"/>
> </map:transform>
> <map:serialize/>
> </map:match>
>
> Note: This application currently "streams-in" the SOAP documents returned
> from web-services to the main XML document and relies on the stylesheet to
> pickup appropriate fields. A better approach is perhaps to use XScript. I am
> still investigating/experimenting with this option.
>
> /Pankaj.
>
> ATTACHMENT part 2 application/octet-stream name=zipcode-info.xsl
> ATTACHMENT part 3 application/octet-stream name=zipcode-info.xsp
> ATTACHMENT part 4 application/octet-stream name=SOAPHelper.java
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
=====
Davanum Srinivas - http://jguru.com/dims/
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org