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.

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Reply via email to