dsmiley opened a new pull request #1600:
URL: https://github.com/apache/lucene-solr/pull/1600


   Convert String and File paths to Path API.
   
   CoreContainer seems to me the proper place for the node to expose key 
directories at a node level.  It's already doing this.  It looked a bit clumsy 
to me to have the String constant and extra methods elsewhere for userfiles.  
And I'd rather not see SolrDispatchFilter touched whatsoever for this feature, 
even if it was one line.
   
   Once I moved that, and declared as type Path, I couldn't un-see all the code 
that did heavy back & forth conversion between String paths and File paths.  
Not only is String terrible because it's untyped, but Path is the modern 
replacement, not File.  I wish we could do forbiddenAPI on File but there's 
lots of old code.  This userfiles code was only added last year though.
   
   I experimented with using Files.walkTree in findReadableFiles() but backed 
off because I already extended my scope very far and I'd rather eventually see 
all of the Files streamed instead of needing to materialize _all_ of them into 
a list. Also, findReadableFiles is pretty clear and wasn't any clearer when I 
played with a Files.walkTree considering all the rules, particularly ignoring 
files that aren't readable.  I wonder how intentional that is... maybe it 
actually _should_ be an error instead of silently ignoring those files.
   
   @gerlowskija 


----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org

Reply via email to