On Wed, Mar 3, 2010 at 11:14 AM, Luciano Resende <[email protected]> wrote: > On Tue, Mar 2, 2010 at 1:58 PM, ant elder <[email protected]> wrote: >> On Sat, Feb 27, 2010 at 7:50 AM, Luciano Resende <[email protected]> >> wrote: >>> Kelvin has identified a issue with store-webapp [1], and after some >>> investigation I tried to summarize the current behavior in the >>> following wiki page [1] >>> >>> Let's use this thread to agree on what we think should be the proper >>> behavior, and then try to have a final solution to this issue, as >>> similar issues had come multiple times in the past [3][4] >>> >>> [1] http://www.mail-archive.com/[email protected]/msg02268.html >>> [2] >>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Embedded+versus+Hosted+web+app+uri >>> [3] http://www.mail-archive.com/[email protected]/msg10134.html >>> [4] http://www.mail-archive.com/[email protected]/msg10284.html >>> >>> -- >>> Luciano Resende >>> http://people.apache.org/~lresende >>> http://twitter.com/lresende1975 >>> http://lresende.blogspot.com/ >>> >> >> Luciano chatted to me off list about this so i had a look whats going on: >> >> 1 - when Tuscany is running embedded inside a webapp all the SCA >> services will be registered at URLs relative to the URL that the >> Tuscany ServletFilter is registered at, usually we register the filter >> at /* so the SCA service URLs will be relative to the context path of >> the webapp, which in Tomcat defaults to the webapp name. Eg for a >> webapp named sample-store-webapp running on a server at localhost port >> 8080 and an SCA service URI of Catalog the absolute URL to the service >> would be http://localhost:8080/sample-store-webapp/Catalog >> >> 2 - from a browser a relative URL that doesn't start with a slash >> character (/) will be relative to base URL of the page. Eg for >> http://localhost:8080/sample-store-webapp/store.html the base url is >> http://localhost:8080/sample-store-webapp so then using a relative URL >> "Catalog" the absolute URL used would be >> http://localhost:8080/sample-store-webapp/Catalog >> >> 3 - a relative URL starting with a slash character will be relative to >> the base URL with the entire path removed. So in an HTML page if the >> base url is http://localhost:8080/sample-store-webapp and the SCA >> service URI is /Catalog the absolute URL would >> http://localhost:8080/Catalog which from the above example wont work >> as thats not where the service is at. >> >> 4 - when running in the Tuscany standalone runtime all the above still >> applies but there is no webapp context path and the base URL path is >> usually left empty, eg just http://localhost:8080, (but it is possible >> to define a path on the HTTP base URL via the Tuscany APIs). >> >> So, from the above item 3 browser JavaScript probably shouldn't be >> using relative URLs starting with a slash, which for >> implementation.widget means that the JavascriptProxyFactory impls >> should be either removing the leading slash in the targetPath when >> generating the JavaScript code or else taking account of the base URL >> and manually adding that to the targetPath. >> >> Doing the simple fix of just removing the leading slash gets the >> store-webapp sample working, but it breaks the standalone store >> sample. Thats because the standalone sample uses a binding.http with a >> uri of "/store", so the Store.html page has a base URL of >> http://localhost:8080/store and thats used by the generated JavaScript >> as the base URL for the SCA services, eg >> http://localhost:8080/store/Catalog but the services are registered at >> http://localhost:8080/Catalog. Changing the binding.http to not use >> the URI attribute doesn't seem to work which seems like a bug in the >> http binding code but using a uri of "/" does work and then both the >> standalone and webapp based store samples run ok for me. >> >> I could check these three changes in as it seems to get everything >> working but it does seem a little fragile, if anyone does ever use a >> uri in the http binding or change the base uri then it would break >> again.I wonder if the Tuscany binding.http should really be trying to >> do all this, if anyone wants to have a full blown web application it >> might be easier to just use a real JEE webapp. >> >> ...ant >> > > Thanks for double checking... could you send a patch of your changes > so I can take a quick look. >
Was easier to just check them in so did that in 918221 - 918223 so you can see what i meant, feel free to revert or modify. The build does go through cleanly like this. ...ant
