[
https://issues.apache.org/jira/browse/SOLR-15462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427859#comment-17427859
]
Carlos Grappa commented on SOLR-15462:
--------------------------------------
Hi! I'd like to fix this issue if possible.
For what I could glean from the code, the main challenge is that FileDetails
doesn't expose the file's name.
However, it can be fixed without making changes to the interface by using the
FileDetails::toMap
What I'm not so sure about, is how to properly test this changes. Ideally I'd
use mockito but I'm not so sure that it'd fit here.
> Dubious code in DistribPackageStore::refresh
> --------------------------------------------
>
> Key: SOLR-15462
> URL: https://issues.apache.org/jira/browse/SOLR-15462
> Project: Solr
> Issue Type: Task
> Components: Package Manager
> Reporter: Mike Drob
> Priority: Major
> Labels: newdev
>
> The code in DistribPackageStore::refresh is slightly dubious. Discovered
> while working on SOLR-15385...
> {code:java}
> @SuppressWarnings({"rawtypes"})
> List l = null;
> l =
> coreContainer.getZkController().getZkClient().getChildren(ZK_PACKAGESTORE +
> path, null, true);
> @SuppressWarnings({"rawtypes"})
> List myFiles = list(path, s -> true);
> for (Object f : l) {
> // TODO: XXX DUBIOUS XXX
> // l should be a List<String> and myFiles should be a
> List<FileDetails>, so contains should always return false!
> if (!myFiles.contains(f)) {
> {code}
> This is concerning because if we have proper typing, then {{contains}} should
> always return false. Are we always downloading the files and improperly
> caching the results?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
