On Thu, Oct 23, 2008 at 5:17 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
> ant elder wrote: > >> >> >> On Tue, Oct 21, 2008 at 12:17 AM, Luciano Resende <[EMAIL PROTECTED]<mailto: >> [EMAIL PROTECTED]>> wrote: >> >> Ok, how about we make a step back and think on the sample scenario : >> >> Considering a client application accessing a sca service using a web >> service binding, if the service were deployed in a different machine >> (e.g luck.apache.org:8080 <http://luck.apache.org:8080> versus >> dhaval.apache.org:8081 <http://dhaval.apache.org:8081>), the >> composite used by the client application would have to be changed to >> point to the proper service. In this application, we are getting >> confused because the client and the service are all archived together >> in the same web application. >> >> I think that's a fair comment (i.e., that I was confused when I wrote the > original comment that kicked off this discussion :-) For a service binding > in a webapp, it should definitely not be necessary to hardwire a host/port. > For a reference binding, there isn't really any way to avoid this without > solving issues 1 and 2 as described by Ant below. > > To avoid future issues, and to make things clear, you could split the >> application into two web apps, a client and a service. >> >> >> Heh. but that doesn't really solve the reported issue - "It should be >> possible to create a (sample) WAR that can be deployed to different port >> numbers without needing to be changed." >> >> I think there are three parts to this: >> >> 1) The Tuscany webapp runtime doesn't have a proper "Base URI" (see >> Assembly spec) so there is no way to wire with binding.ws < >> http://binding.ws> without an absolute endpoint URL. So the earlier >> suggestion to use a relative URL doesn't work and nor would using the target >> attribute on the reference like this: >> >> <reference name="addService" target="AddServiceComponent"> >> <binding.ws <http://binding.ws> /> >> </reference> >> >> 2) The Tuscany webapp runtime has no way to automatically determine that >> Base URI so even if (1) was fixed we couldn't do it automatically. The >> problem here is that there is no way for code running in a webapp to >> programatically find the URL to the webapp before a request comes in. - what >> is the host name and port? You just don't know. Ok for this sample you might >> be able to assume a hostname of 'localhost' but you don't know the port >> number. If we fixed (1) then we could add a webapp env-entry to configure >> the Base URI and IMHO that would make things much clearer than having to >> hunt around the SCDL looking for the URLs that need changing. >> >> 3) What is it that the sample is trying to show? I guess its showing using >> SCA services and references using the Web Service binding with the Tuscany >> webapp runtime, but is that - creating and using external web service >> endpoints - or - wiring within an SCA domain using binding.ws < >> http://binding.ws>? If its the first of those maybe we should split the >> sample into two seperate webapps but that makes the sample more complicated >> and the issue reported here would still exist - you would still need to >> update the client for the absolute service endpoint. We already have some >> seperate helloworld type samples with seperate WS services and references >> and having this one a single sample is useful, i use it a lot as a quick and >> easy way to see things are working ok. >> >> Would be good to fix (1) and (2). Until then for this sample I think it >> might be easiest for now to just document in the README that you need to >> update the URLs in the SCDL to match where the webapp is deployed. >> >> +1 for fixing (1) and (2). > > The README for calculator-ws-webapp already says this, so no change is > required here. However, helloworld-ws-sdo-webapp has a similar problem > (in this case it's the WSDL that needs to be changed) and its README > doesn't mention this, so this should be updated. > > Simon > > I've raise a JIRA for this - TUSCANY-2652 ...ant
