On Wed, Oct 28, 2009 at 1:46 AM, ant elder <[email protected]> wrote: > On Wed, Oct 28, 2009 at 8:15 AM, ant elder <[email protected]> wrote: >> On Wed, Oct 28, 2009 at 4:09 AM, Luciano Resende <[email protected]> >> wrote: >>> On Tue, Oct 27, 2009 at 8:03 AM, ant elder <[email protected]> wrote: >>>> On Tue, Oct 27, 2009 at 2:56 PM, Luciano Resende <[email protected]> >>>> wrote: >>>> >>>> >>>>> I don't see any errors running the build, but any war that I build and >>>>> then deploy in tomcat fails (e.g the service endpoint is unavailable). >>>> >>>> I've tried this on Tomcat too and its working fine for me so it must >>>> be something more complex and a difference in our environments. Happy >>>> to help debug if you ping me when you're ready to recreate. Can anyone >>>> else try one of the webapp samples and see if it is/isn't working for >>>> you? >>>> >>> >>> I did a quick search on the samples we have today in 2.x and it seems >>> that we don't have any webapp that is exposing services and all the >>> wiring and execution are happening on the server. You could check the >>> sample on the cloud sandbox [1] and try to deploy it to tomcat to see >>> the problem... I'll be looking into the issue again now as well. >>> >>> [1] >>> https://svn.apache.org/repos/asf/tuscany/sandbox/sca-cloud-tutorial/store-catalog-ibmcloud-webapp/ >>> >>> >> >> Looking that app you point to i think it will be caused by the uri in >> the binding definition: >> >> <tuscany:binding.jsonrpc >> uri="http://localhost:8080/store-catalog-ibmcloud-webapp/Catalog"/> >> >> In the webapp environment we can't set the root of the url so the >> webapp host just removes it and i expect thats why you end up with the >> unexpected path. I'll go take a look at the code thats doing the >> striping of the root to see if it can take account of the duplicated >> context. But why are you including the uri? >> <tuscany:binding.jsonrpc/> would be simpler and in 2.x works well now >> that the computed uri works properly. I believe some SCA runtimes >> actually throw an error in this situation instead of just ignoring the >> root so its probably best to not have it when its not really needed. >> >> ...ant >> > > I've traced through the code and that is whats happening. I'm not > totally convinced we should change this behaviour though and wonder > wouldn't it be better to just not be having the hardcoded absolute uri > in the binding? What do people think? > > ...ant >
Absolute URI works.. I'll just switch the sample app to use that. -- Luciano Resende http://people.apache.org/~lresende http://lresende.blogspot.com/
