Hi all,
could you please review this small patch?
according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in
MLSx response have the following format:
>time-val = 14DIGIT [ "." 1*DIGIT ]
>
>The leading, mandatory, fourteen digits are to be interpreted as, in
>order f
On Thu, 22 Oct 2020 10:33:06 GMT, Daniel Fuchs wrote:
> Hi Igor, is this testable - and if so shouldn't there be a test?
> best regards,
> -- daniel
Hi Daniel,
it's testable and originally I planned to add a new test, however upon checking
the existing mock ftp-servers, I realized that none of
ormat("MMddhhmmss")` (which is
> wrong b/c it uses `hh` instead of `HH` and doesn't account for optional
> `.sss`) to parse modify/create facts and ignore any parse exceptions.
>
> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats
> i
On Thu, 22 Oct 2020 16:04:56 GMT, Igor Ignatyev wrote:
>> Hi Igor, is this testable - and if so shouldn't there be a test?
>> best regards,
>> -- daniel
>
>> Hi Igor, is this testable - and if so shouldn't there be a test?
>> best regards,
>>
ormat("MMddhhmmss")` (which is
> wrong b/c it uses `hh` instead of `HH` and doesn't account for optional
> `.sss`) to parse modify/create facts and ignore any parse exceptions.
>
> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats
> i
On Fri, 23 Oct 2020 18:05:07 GMT, Daniel Fuchs wrote:
>> Igor Ignatyev has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use only filename in assert message
>
> Thanks for adding a test Igor!
> If that
On Tue, 20 Oct 2020 23:14:40 GMT, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this small patch?
>
> according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in
> MLSx response have the following format:
>>time-val = 14DIGIT [ &quo
On Sun, 25 Oct 2020 00:35:20 GMT, Marcono1234
wrote:
>> Igor Ignatyev has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> use only filename in assert message
>
> src/java.base/share/classes/sun/net/ftp
Hi all,
could you please review this small and trivial fix?
`sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat`
which are shared among all instances of `FtpClient`. the fact that
`SimpleDateFormat` isn't thread-safe renders`FtpClient` to be non-thread-safe
as well. the p
ent` to be non-thread-safe
> as well. the patch makes the only usage of `dateFormats` array,
> `parseRfc3659TimeValue` method, `synchronized`.
>
> the problem was reported in #776
>
> Thanks,
> -- Igor
Igor Ignatyev has updated the pull request incrementally with th
On Tue, 27 Oct 2020 12:48:58 GMT, Chris Hegarty wrote:
>> Hi all,
>>
>> could you please review this small and trivial fix?
>>
>> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat`
>> which are shared among all instances of `FtpClient`. the fact that
>> `SimpleDateForm
ent` to be non-thread-safe
> as well. the patch makes the only usage of `dateFormats` array,
> `parseRfc3659TimeValue` method, `synchronized`.
>
> the problem was reported in #776
>
> Thanks,
> -- Igor
Igor Ignatyev has updated the pull request incrementally with two addit
On Mon, 26 Oct 2020 16:51:25 GMT, Igor Ignatyev wrote:
> Hi all,
>
> could you please review this small and trivial fix?
>
> `sun/net/ftp/imp/FtpClient::dateFormats` is an array of `SimpleDateFormat`
> which are shared among all instances of `FtpClient`. the fact that
&
On Wed, 28 Oct 2020 12:52:41 GMT, Rahul Yadav wrote:
>> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 1770:
>>
>>> 1768: try {
>>> 1769: var d = LocalDateTime.parse(s, RFC3659_DATETIME_FORMAT);
>>> 1770: result =
>>> Date.from(d.atZone(ZoneOffs
On Wed, 28 Oct 2020 18:07:28 GMT, Daniel Fuchs wrote:
>> Igor Ignatyev has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - use UTC TZ for RFC3659_DATETIME_FORMAT
>> - run TestFtpTimeValue with differe
15 matches
Mail list logo