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-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: <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





Reply via email to