Bug 361450

Comment 1 Mark Macdonald 2011-10-21 18:12:45 EDT

The file's metadata refers to the outer hostname, and so can't be XHR'd from the inner site:

{
  ExportLocation: "http://localhost:8080/xfer/export/ac/bundles/org.eclipse.orion.client.core/web/edit/edit.js.zip",
  ImportLocation: "http://localhost:8080/xfer/import/ac/bundles/org.eclipse.orion.client.core/web/edit/edit.js",
  Location: "http://localhost:8080/file/ac/bundles/org.eclipse.orion.client.core/web/edit/edit.js",
  SearchLocation: "http://localhost:8080/filesearch?q=",
   ...
}

Aside: global search doesn't do any error handling, so this failure is invisible in the UI.

Comment 2 libing wang 2011-10-24 10:19:24 EDT

(In reply to comment #1)
> The file's metadata refers to the outer hostname, and so can't be XHR'd from
> the inner site:
> 
> {
>   ExportLocation:
> "http://localhost:8080/xfer/export/ac/bundles/org.eclipse.orion.client.core/web/edit/edit.js.zip",
>   ImportLocation:
> "http://localhost:8080/xfer/import/ac/bundles/org.eclipse.orion.client.core/web/edit/edit.js",
>   Location:
> "http://localhost:8080/file/ac/bundles/org.eclipse.orion.client.core/web/edit/edit.js",
>   SearchLocation: "http://localhost:8080/filesearch?q=",
>    ...
> }
> 
The searcher inside an editor asks the input manager to give back the search Location, while the global Command hard coded the search Location but the host name part is resolved by require.toUrl.
That is why search from the global command bar is working.
We should really consolidate the way we are using search Location in all the entries. Or, more generically the file meta data should give back reasonable locations.

But the thing surprised me is that in the search result page I am using file meta data to get the file's parent chain. If it is working, it implies that my file meta data is pointing to the inner site. Maybe the simplest solution is to see if we can resolve the issue in the input manager at the first place.(e.g. fileClient.read(innerURL, true).

> Aside: global search doesn't do any error handling, so this failure is
> invisible in the UI.
Not sure about this. The file meta data is managed by the editor's input manager. Do you mean we should show some error when inputManager.fileClient.read() got some errors? I think search Client already handled error when search fails.

Comment 3 Mark Macdonald 2011-10-24 12:38:59 EDT

(In reply to comment #2)
> We should really consolidate the way we are using search Location in all the
> entries.

Looks like the patch for Bug 361476 will consolidate this.

> But the thing surprised me is that in the search result page I am using file
> meta data to get the file's parent chain. If it is working, it implies that my
> file meta data is pointing to the inner site. Maybe the simplest solution is to
> see if we can resolve the issue in the input manager at the first place.(e.g.
> fileClient.read(innerURL, true).

Some metadata is correct (eg. Parents) but some isn't (eg. *Location). I need to fix this on the server side -- the client would have to make bad assumptions to correct this by itself.

> The file meta data is managed by the editor's input manager. Do you mean we 
> should show some error when inputManager.fileClient.read() got some errors?
> I think search Client already handled error when search fails.

No, in this case the metadata request works OK, it's the search request that fails. And SearchClient doesn't handle the rejected promise generated by the failure.

Comment 4 Mark Macdonald 2011-10-24 16:57:26 EDT

The code that fixes up URLs was not being called for a "GET metadata" operation. 

http://git.eclipse.org/c/orion/org.eclipse.orion.server.git/commit/?id=1224bd07c49feeae8a12e2bd7343da3c7a001067