Simon Nash wrote:
Raymond Feng wrote:
Hi,
I did some investigation and it turned out it is not a trivial issue.
Recently we now move the Java2WSDL generation to the build phase.
When Tuscany is deployed as a web application, we don't know the HTTP
port number configured when the Tuscany runtime is bootstrapped by the
ServletFilter. The information is only available when the HTTP request
comes. Simon Nash can probably provide more information about the
changes.
There is code in the Axis2 Web Service binding provider that is intended
to resolve this information at runtime (i.e., before the Axis2 service
is started). See the call to servletHost.getURLMapping(uri) in
Axis2ServiceProvider.computeEndpointURI(). The provider should call this
and us ethe result to fix up the port URI in the WSDL document that's used
by Axis2 to return the ?wsdl information. I'll investigate further to see
why this is not happening.
I added debug printouts around this call. Here's the input and output:
input uri configured by the builder == /AddServiceComponent
output uri returned by getURLMapping(uri) ==
http://SouthRim:8080/sample-calculator-ws-webapp/AddServiceComponent;
My Tomcat server.xml file is configured to use port 8090. Why is
ServletHost.getURLMapping() returning 8080? If this could be fixed,
no other changes would be needed for ?wsdl to work correctly.
Simon
Simon
The fundamental issue is that the composite is not fully resolved in
the SCA domain before it's deployed to a node. The SCADomain API is a
shortcut that assumes there is a single SCA contribution and the
deployable composite is fully resolved.
Now we have different options to work around or fix the problem:
1) Add uri for binding.ws with the absolute address where the web
application is deployed.
2) Switch to a strategic approach with the latest SCA Node APIs with a
few changes for you webapp. Please see an example at [1].
a) Change the web.xml to use another servlet filter:
filter
filter-nametuscany/filter-name
filter-classorg.apache.tuscany.sca.node.launcher.NodeServletFilter/filter-class
/filter
b) Define a system property or environment variable TUSCANY_DOMAIN
which points to a URL that contains the resolved node configuration as
an ATOM feed. The URL can be a http URL if you have the domain admin
application running. Otherwise, you can create an file named as the
webapp in the domain_url/node-config/ folder. The content of the
file is an ATOM feed illustrated below. The first entry is for the
resolved composite and the others are for the required contributions.
?xml version='1.0' encoding='UTF-8'?
feed xmlns=http://www.w3.org/2005/Atom;
title type=textNode Configuration/title
entry
idcomposite:store;http://store;store/id
title type=textstore - http://store;store/title
content type=html /
link
href=/composite-resolved/composite:store;http://store;store; /
/entry
entry
idassets/id
title type=textassets/title
content type=html /
link href=/contribution/assets /
link
href=file:/C:/Tuscany/java/sca/tutorial/domain/../assets/target/tutorial-assets.jar
rel=alternate /
/entry
entry
idstore/id
title type=textstore/title
content type=html /
link href=/contribution/store /
link
href=file:/C:/Tuscany/java/sca/tutorial/domain/../store/target/tutorial-store.jar
rel=alternate /
/entry
/feed
c) Optionally define a TUSCANY_HOME and/or TUSCANY_PATH which points
to the tuscany distro outside the web application. This way, we don't
have to physically embed the Tuscany and 3rd party jars into the web
application.
Thanks,
Raymond
[1]
http://svn.apache.org/repos/asf/tuscany/java/sca/tutorial/catalog-webapp
[2]
http://svn.apache.org/repos/asf/tuscany/java/sca/tutorial/catalog-webapp/webapp/WEB-INF/web.xml
--
From: Dave Sowerby [EMAIL PROTECTED]
Sent: Wednesday, July 16, 2008 3:07 AM
To: dev@tuscany.apache.org
Subject: Webservices port issue with Tuscany 1.3
Hi All,
I'm undertaking an upissue for some services from Tuscany 1.2.1 to
Tuscany 1.3 (using RC1), and I'm facing an issue with the generated
wsdl.
If I deploy these services to Websphere 6.1 on Windows the
soap:address generated is always in the form:
soap:address location=http://ip:8080/context/component/
Such that the port is fixed at 8080, regardless of the true service uri.
Is this something anyone else has seen previously? Is there anything
obviously wrong that would cause this issue? I'm simply using
binding.ws / in my composite and can't see anything invalid in my
service - especially given the fact these worked fine in 1.2.1 before
the wsdl generation rewrite.
Cheers,
Dave.
--
Dave Sowerby MEng MBCS
