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.
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-name>tuscany</filter-name>
<filter-class>org.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="text">Node Configuration</title>
<entry>
<id>composite:store;http://store;store</id>
<title type="text">store - http://store;store</title>
<content type="html" />
<link href="/composite-resolved/composite:store;http://store;store";
/>
</entry>
<entry>
<id>assets</id>
<title type="text">assets</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>
<id>store</id>
<title type="text">store</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: <[email protected]>
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
