Community
Participate
Working Groups
After installing the webdav file service I get the following error when I do a search... No Matching FileService for location:?sort=Path asc&rows=40&start=0&q=test If I uninstall webdav it works fine again.
Simon, can you tell me how to install/uninstall the webdav stuff?
Libing, you can install webdav by using the plugin http://orion.eclipse.org:8080/plugins/webdavFilePlugin.html I have no idea how to configure it, but at least it puts you in the mode. There is also a sample file plugin (but I haven't tried it yet). In bug 368282 I changed the navigator implementation so that the navigator is typically showing content from only one file system. The way I think search should work is: - when you are looking at a navigator, use the file system of that navigator - likewise if you are in an editor, use the file system of that editor - I implemented a special mode that interprets the path "/" as being the root of all file systems. If that is the user's path, then we should be searching all file systems. So in some ways, a file system is just like a scoped search. The main change in bug 368282 is that most of the time the navigator is dealing with one system at a time. But the path "/" can still be used to deal with all file systems as a single lookup tree. At a minimum, I think that if the user is using the navigator with path "/" then the search should likewise be looking across file systems. We may realize later that we want some other way to represent "all file systems" in the breadcrumb or somewhere else, so that the user could "back up" from one file system to all file systems. (Note that this is not a problem special to search. The breadcrumb for multi file systems never worked because the breadcrumb has never been able to represent this mode.)
(In reply to comment #2) > Libing, you can install webdav by using the plugin > http://orion.eclipse.org:8080/plugins/webdavFilePlugin.html This plugin is no working but I setup the Win7 IIS with WebDav and installed the webdev plugin. Now I can see 2 file systems. > - I implemented a special mode that interprets the path "/" as being the root > of all file systems. If that is the user's path, then we should be searching > all file systems. I tried to use "/" so that all the file systems are rendered in the navigator. When I search I got no errors mentioned by Simon but it seems Orion just ignored the file service from webDav. If I select WebDav on the left pane and do search, I got errors like this: GET http://localhost:8080/filesearch?sort=Path%20asc&rows=40&start=0&q=asdfasdfa+Location:http://localhost/project/plugin/* 500 (org.apache.solr.client.solrj.SolrServerException: org.apache.solr.common.SolrException: org.apache.lucene.queryParser.ParseException: Cannot parse '*asdfasdfa* AND Location:http://localhost/project/plugin/* AND UserName:wwww': Encountered " ":" ": "" at line 1, column 29. Was expecting one of: <EOF> <AND> ... <OR> ... <NOT> ... "+" ... "-" ... "(" ... "*" ... "^" ... <QUOTED> ... <TERM> ... <FUZZY_SLOP> ... <PREFIXTERM> ... <WILDTERM> ... "[" ... "{" ... <NUMBER> ...) dojo.xhrdojo.js.uncompressed.js:10694 dojo.xhrGetdojo.js.uncompressed.js:10708 FileServiceImpl.searchfileImpl.js:401 _handleRequest This is because my file service still refers to Orion and it thinks it should search on the indexer. Apparently the searcher is not using the file service passed by boot strap. We need to fix that part. One solution is not to implement search function so that we will know search is not available and we can tell user that search is not avaible.
I can't speak for webdav plugin. If it doesn't implement search, then the best we could do is report some kind of user error "search not supported in this file system" But I think that for the case where you are looking at all roots, search should try to search each file system. That is not implemented right now. In fileClient.js line 164, the top level file system doesn't implement search. And below at fileClient.js line 428, the search method is just looking up a service with no location, so it will default to the first one. If we want to be cool, we should implement the search method at line 428 to walk each file system root and perform a search at that level, concatenating the results. It's similar to the way that cross-system file/copy is implemented, with fileClient knowing how to deal with multiples. I think Simon should define the requirements here. - Do we need to support cross-file system search? - If we do, then fileClient needs to implement the aggregation of the results. - And if we do, then right now the only way in the UI is to know the "/" secret in the navigator...
fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a0ce7ea78c71a0abe97ac54df3e89f542ed30837. It is not a perfect solution but at least it tells user that search is not supported on the file system that does not implement search. So now if you click on the webDav file system on the left pane of the navigator and do search, you will see error message in the result page saying "search is not supported". If you are on the top level, as we are not walking each file system anyway, you will always use the Orion file system and the webDev location is not used at all. So it will only search on Orion file system.
