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
