On Tue, Mar 2, 2010 at 11:21 PM, ant elder <[email protected]> wrote: > 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 >
Hi Luciano, you've just reverted this change without any explanation, would you say more? ...ant
