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
