[
https://issues.apache.org/jira/browse/SOLR-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15002125#comment-15002125
]
Alan Woodward commented on SOLR-8282:
-------------------------------------
There are a whole bunch of smallish steps that can be taken here (SOLR-8260 and
SOLR-8278 are the first ones). I think it's important to try and do this
piece-wise, as changing everything at once ends up with massive patches that
are difficult to review.
I see a number of steps here:
* Firstly, try and move our internal APIs that deal with file paths away from
using Strings to represent those paths, using Path instead. For example,
SolrResourceLoader takes a String to point to its instance directory, as does
CoreDescriptor. I have a half-done patch for SRL already, which I will open a
separate ticket for. SolrCore.getDataDir() and CoreContainer.getSolrHome() are
also candidates here.
* Ban use of java.io.File in core, and try and load everything either through
SolrResourceLoader or via SolrCore.getDataDir().
* Ban use of java.io.File in core tests. This will likely take the longest.
* Ban use of Paths.get() in core and core tests, expect for a few places (eg
SolrDispatchFilter). This will mean that all file system resolution is done
via SolrResourceLoader, and we can try and do interesting things like use the
lucene exception-throwing file systems to test resilience.
> Move Solr internal APIs to NIO2, and ban use of java.io.File
> ------------------------------------------------------------
>
> Key: SOLR-8282
> URL: https://issues.apache.org/jira/browse/SOLR-8282
> Project: Solr
> Issue Type: Improvement
> Reporter: Alan Woodward
>
> This is an umbrella issue for removing all usage of java.io.File from Solr,
> and replacing it with NIO2.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
