[
https://issues.apache.org/jira/browse/NET-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14229304#comment-14229304
]
Sebb commented on NET-544:
--------------------------
Agreed, if the parserKey is null then the entry is recreated.
This currently has the side effect that if the System property or the SYST
response changes, the parser will be created from the new value.
Now the SYST response is cached, so it cannot change, and the System property
is intended for use on the command-line.
It therefore seems extremely unlikely that any code relies on this behaviour.
The code therefore just needs to check the parserKey if it is non-null.
> initiateListParsing does not correctly check if parserKey was cached
> --------------------------------------------------------------------
>
> Key: NET-544
> URL: https://issues.apache.org/jira/browse/NET-544
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.3
> Reporter: Olivier Queyrut
> Priority: Minor
>
> At line 3232 of FTPClient, it is mentionned that the parserKey and
> entryParser are cached "to avoid creation of a new object every time a file
> listing is generated".
> However the test seems to be incorrect as a new entryParser is created every
> time the method "listFiles" is called. Indeed, in method named listFiles, the
> initiateListParsing is called with a null argument for the parserKey.
> So the test : "if(__entryParser == null || !
> __entryParserKey.equals(parserKey))" is always true (even if __entryParserKey
> has been cached) and thus a new entryParser is created.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
