Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 397473

Summary: Issues when mounting Orion file system to Orion Node.
Product: [ECD] Orion Reporter: libing wang <libingw>
Component: NodeAssignee: libing wang <libingw>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: john.arthorne, mamacdon, simon_kaegi
Version: 1.0   
Target Milestone: 2.0 M2   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description libing wang CLA 2013-01-04 15:03:16 EST
It might be a rare case but it happened when I tried to test multiple file systems on Orion node.
Talked to John, he said its better to resolve on server side.
Steps.
1.Start Orion node
2.In the setting page, mount https://orion.eclipse.org/plugins/fileClientPlugin.html as another file system.
3.Open navigator in Orion node, and click on "Orion Content" file system on the left hand side.
4.Global search some thing. Or do file search.
5.In the debugger console you will see this:

GET https://orion.eclipse.org/filesearch?sort=Path%20asc&rows=40&start=0&q=function+Location:https://orion.eclipse.org/file/R/OrionClient/* 500 (org.apache.solr.client.solrj.SolrServerException: org.apache.solr.common.SolrException: org.apache.lucene.queryParser.ParseException: Cannot parse '*function* AND Location:https://orion.eclipse.org/file/R/OrionClient/* AND UserName:liwang': Encountered " ":" ": "" at line 1, column 29. Was expecting one of:     <EOF>      <AND> ...     <OR> ...     <NOT> ...     "+" ...     "-" ...     "(" ...     "*" ...     "^" ...     <QUOTED> ...     <TERM> ...     <FUZZY_SLOP> ...     <PREFIXTERM> ...     <WILDTERM> ...     "[" ...     "{" ...     <NUMBER> ...)


This is because the Location param of the search includes the host part, which is not recognized by the server.
Comment 1 libing wang CLA 2013-01-04 16:35:17 EST
I've changed the abstraction to a generic one.
Basically when the resource location contains the host in the URL, not only the search but also the copying does not work well.
In the copy case:
1. If you copy from Orion file system to Node file system, the fileClient assumes that the source location always starts with "/" then it adds "depth=1" at the end. If the source location starts with a host name, then the fetch children will fail because there is no "depth=1" added.
2. If you copy from Orion node to Orion, the write file request fails.
Comment 2 libing wang CLA 2013-01-04 16:53:01 EST
The solution of the copy issue seems to be simple:
If I remove line 5 6and 58 in fileClient.js like this 
			//if (sourceLocation.indexOf("/") === 0) { //$NON-NLS-0$
				sourceLocation += "?depth=1"; //$NON-NLS-0$
			//}


The copy works because the fetch children returns something.
But I am nor quite sure why line 56 was there before, need to talk to Simon later.