[jira] [Commented] (NET-731) FTPSClient no longer supports fileTransferMode (eg DEFLATE)
[
https://issues.apache.org/jira/browse/NET-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851675#comment-17851675
]
PJ Fanning commented on NET-731:
[https://github.com/apache/commons-net/pull/90] was first release in
commons-net 3.10.0.
The new openDataSecureConnection method is kind of copy/paste of the FTPClient
method.
{noformat}
_openDataConnection_
{noformat}
But in the copy/paste, the call to `wrapOnDeflate` was dropped.
> FTPSClient no longer supports fileTransferMode (eg DEFLATE)
> ---
>
> Key: NET-731
> URL: https://issues.apache.org/jira/browse/NET-731
> Project: Commons Net
> Issue Type: Task
> Components: FTP
>Reporter: PJ Fanning
>Priority: Major
>
> The new openDataSecureConnection method in FTPSClient does not support
> fileTransferMode (eg DEFLATE).
> [https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9[]
>
> |https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9]
>
> The FTPSClient code used to delegate to FTPClient
> {noformat}
> _openDataConnection_
> {noformat}
> method.
> [https://github.com/apache/commons-net/blob/b5038eff135dff54e2ee2d09b94ec7d8937cb09b/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L696]
> This method supports `wrapOnDeflate` while openDataSecureConnection does not.
> I'm not sure if FTPS supports DEFLATE transfer mode but while implementing an
> Apache Pekko workaround for the NET-718, I spotted the diff.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NET-731) FTPSClient no longer supports fileTransferMode (eg DEFLATE)
[
https://issues.apache.org/jira/browse/NET-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
PJ Fanning updated NET-731:
---
Description:
The new openDataSecureConnection method in FTPSClient does not support
fileTransferMode (eg DEFLATE).
[https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9[]
|https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9]
The FTPSClient code used to delegate to FTPClient
{noformat}
_openDataConnection_
{noformat}
method.
[https://github.com/apache/commons-net/blob/b5038eff135dff54e2ee2d09b94ec7d8937cb09b/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L696]
This method supports `wrapOnDeflate` while openDataSecureConnection does not.
I'm not sure if FTPS supports DEFLATE transfer mode but while implementing an
Apache Pekko workaround for the NET-718, I spotted the diff.
was:
The new openDataSecureConnection method in FTPSClient does not support
fileTransferMode (eg DEFLATE).
[https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9[]
|https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9]
The FTPSClient code used to delegate to FTPClient `_openDataConnection_`.
[https://github.com/apache/commons-net/blob/b5038eff135dff54e2ee2d09b94ec7d8937cb09b/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L696]
This method supports `wrapOnDeflate` while openDataSecureConnection does not.
I'm not sure if FTPS supports DEFLATE transfer mode but while implementing an
Apache Pekko workaround for the NET-718, I spotted the diff.
> FTPSClient no longer supports fileTransferMode (eg DEFLATE)
> ---
>
> Key: NET-731
> URL: https://issues.apache.org/jira/browse/NET-731
> Project: Commons Net
> Issue Type: Task
> Components: FTP
>Reporter: PJ Fanning
>Priority: Major
>
> The new openDataSecureConnection method in FTPSClient does not support
> fileTransferMode (eg DEFLATE).
> [https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9[]
>
> |https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9]
>
> The FTPSClient code used to delegate to FTPClient
> {noformat}
> _openDataConnection_
> {noformat}
> method.
> [https://github.com/apache/commons-net/blob/b5038eff135dff54e2ee2d09b94ec7d8937cb09b/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L696]
> This method supports `wrapOnDeflate` while openDataSecureConnection does not.
> I'm not sure if FTPS supports DEFLATE transfer mode but while implementing an
> Apache Pekko workaround for the NET-718, I spotted the diff.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NET-731) FTPSClient no longer supports fileTransferMode (eg DEFLATE)
[ https://issues.apache.org/jira/browse/NET-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PJ Fanning updated NET-731: --- Description: The new openDataSecureConnection method in FTPSClient does not support fileTransferMode (eg DEFLATE). [https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9[] |https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9] The FTPSClient code used to delegate to FTPClient `_openDataConnection_`. [https://github.com/apache/commons-net/blob/b5038eff135dff54e2ee2d09b94ec7d8937cb09b/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L696] This method supports `wrapOnDeflate` while openDataSecureConnection does not. I'm not sure if FTPS supports DEFLATE transfer mode but while implementing an Apache Pekko workaround for the NET-718, I spotted the diff. was: The new openDataSecureConnection method in FTPSClient does not support fileTransferMode (eg DEFLATE). https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9[ |https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9] The FTPSClient code used to delegate to FTPClient _openDataConnection_ [https://github.com/apache/commons-net/blob/b5038eff135dff54e2ee2d09b94ec7d8937cb09b/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L696] This method supports `wrapOnDeflate` while openDataSecureConnection does not. I'm not sure if FTPS supports DEFLATE transfer mode but while implementing an Apache Pekko workaround for the NET-718, I spotted the diff. > FTPSClient no longer supports fileTransferMode (eg DEFLATE) > --- > > Key: NET-731 > URL: https://issues.apache.org/jira/browse/NET-731 > Project: Commons Net > Issue Type: Task > Components: FTP >Reporter: PJ Fanning >Priority: Major > > The new openDataSecureConnection method in FTPSClient does not support > fileTransferMode (eg DEFLATE). > [https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9[] > > |https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9] > > The FTPSClient code used to delegate to FTPClient `_openDataConnection_`. > [https://github.com/apache/commons-net/blob/b5038eff135dff54e2ee2d09b94ec7d8937cb09b/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L696] > This method supports `wrapOnDeflate` while openDataSecureConnection does not. > I'm not sure if FTPS supports DEFLATE transfer mode but while implementing an > Apache Pekko workaround for the NET-718, I spotted the diff. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NET-731) FTPSClient no longer supports fileTransferMode (eg DEFLATE)
PJ Fanning created NET-731: -- Summary: FTPSClient no longer supports fileTransferMode (eg DEFLATE) Key: NET-731 URL: https://issues.apache.org/jira/browse/NET-731 Project: Commons Net Issue Type: Task Components: FTP Reporter: PJ Fanning The new openDataSecureConnection method in FTPSClient does not support fileTransferMode (eg DEFLATE). https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9[ |https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9] The FTPSClient code used to delegate to FTPClient _openDataConnection_ [https://github.com/apache/commons-net/blob/b5038eff135dff54e2ee2d09b94ec7d8937cb09b/src/main/java/org/apache/commons/net/ftp/FTPClient.java#L696] This method supports `wrapOnDeflate` while openDataSecureConnection does not. I'm not sure if FTPS supports DEFLATE transfer mode but while implementing an Apache Pekko workaround for the NET-718, I spotted the diff. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NET-726) make private fields in FTPSClient protected so it can be subclassed
[ https://issues.apache.org/jira/browse/NET-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804717#comment-17804717 ] PJ Fanning commented on NET-726: Thanks [~ggregory], I'll look into providing a PR with protected getters. It could take me a week before I get around to this. > make private fields in FTPSClient protected so it can be subclassed > --- > > Key: NET-726 > URL: https://issues.apache.org/jira/browse/NET-726 > Project: Commons Net > Issue Type: Task >Reporter: PJ Fanning >Priority: Major > > As part of https://github.com/apache/incubator-pekko-connectors/pull/171, I > am trying to subclass FTPSClient to revert the changes in NET-642 (see > NET-718). > While the method that I need to change is protected, the method needs access > to private fields. > The line I want to revert in the Apache Pekko code is > https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9R269 > > That _openDataConnection_ method uses a number of private final fields. Even > if these fields were provided with protected getter methods, I would be able > to access the values in my subclass. > For now, I've done a full copy of FTPSClient and adjusted that - but that is > a lot of code to keep forked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NET-726) make private fields in FTPSClient protected so it can be subclassed
PJ Fanning created NET-726: -- Summary: make private fields in FTPSClient protected so it can be subclassed Key: NET-726 URL: https://issues.apache.org/jira/browse/NET-726 Project: Commons Net Issue Type: Task Reporter: PJ Fanning As part of https://github.com/apache/incubator-pekko-connectors/pull/171, I am trying to subclass FTPSClient to revert the changes in NET-642 (see NET-718). While the method that I need to change is protected, the method needs access to private fields. The line I want to revert in the Apache Pekko code is https://github.com/apache/commons-net/pull/90/files#diff-b4292a5bd3e39f502d24bce1eb934384a951a120080c870cdc68c0585a78c6e9R269 That _openDataConnection_ method uses a number of private final fields. Even if these fields were provided with protected getter methods, I would be able to access the values in my subclass. For now, I've done a full copy of FTPSClient and adjusted that - but that is a lot of code to keep forked. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NET-718) "Unsupported or unrecognized SSL message" for FTPS via proxy
[
https://issues.apache.org/jira/browse/NET-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748934#comment-17748934
]
PJ Fanning commented on NET-718:
Presumably the change in [https://github.com/apache/commons-net/pull/90] fixes
some issue for some users but breaks FTPS proxy for other users. Maybe one
solution is to introduce a new setting that allows users to turn off the code
in
https://github.com/apache/commons-net/blob/master/src/main/java/org/apache/commons/net/ftp/FTPSClient.java#L794-L796
> "Unsupported or unrecognized SSL message" for FTPS via proxy
>
>
> Key: NET-718
> URL: https://issues.apache.org/jira/browse/NET-718
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Sebastian Alfers
>Priority: Major
>
> After bumping from commons-net 3.8 to 3.9, we started to see this error.
> I happens only when using FTPS via a proxy, and it is likely that this change
> may have introduced.
>
> Any recommendation how to bring back the pre-3.9 behavior? This is the full
> stacktrace:
> {code:java}
> Start of log messages of test that failed with assertion failed:
> fishForMessage(OnNext(_) or OnComplete) found unexpected message
> OnError(javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:451)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:175)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1505)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1420)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> at
> org.apache.commons.net.ftp.FTPSClient.openDataConnection(FTPSClient.java:278)
> at
> org.apache.commons.net.ftp.FTPClient._retrieveFileStream(FTPClient.java:915)
> at
> org.apache.commons.net.ftp.FTPClient.retrieveFileStream(FTPClient.java:2841)
> at
> akka.stream.alpakka.ftp.impl.CommonFtpOperations.$anonfun$retrieveFileInputStream$1(CommonFtpOperations.scala:71)
> at scala.util.Try$.apply(Try.scala:210) {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NET-718) "Unsupported or unrecognized SSL message" for FTPS via proxy
[
https://issues.apache.org/jira/browse/NET-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17748931#comment-17748931
]
PJ Fanning commented on NET-718:
We're seeing this in Apache Pekko FTP connector too. Upgrading from commons-net
3.8.0 to 3.9.0 breaks a FTPS proxy test case - with same exception shown in
description.
> "Unsupported or unrecognized SSL message" for FTPS via proxy
>
>
> Key: NET-718
> URL: https://issues.apache.org/jira/browse/NET-718
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Sebastian Alfers
>Priority: Major
>
> After bumping from commons-net 3.8 to 3.9, we started to see this error.
> I happens only when using FTPS via a proxy, and it is likely that this change
> may have introduced.
>
> Any recommendation how to bring back the pre-3.9 behavior? This is the full
> stacktrace:
> {code:java}
> Start of log messages of test that failed with assertion failed:
> fishForMessage(OnNext(_) or OnComplete) found unexpected message
> OnError(javax.net.ssl.SSLException: Unsupported or unrecognized SSL message
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.handleUnknownRecord(SSLSocketInputRecord.java:451)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:175)
> at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1505)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1420)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:455)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:426)
> at
> org.apache.commons.net.ftp.FTPSClient.openDataConnection(FTPSClient.java:278)
> at
> org.apache.commons.net.ftp.FTPClient._retrieveFileStream(FTPClient.java:915)
> at
> org.apache.commons.net.ftp.FTPClient.retrieveFileStream(FTPClient.java:2841)
> at
> akka.stream.alpakka.ftp.impl.CommonFtpOperations.$anonfun$retrieveFileInputStream$1(CommonFtpOperations.scala:71)
> at scala.util.Try$.apply(Try.scala:210) {code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TEXT-224) set SecureProcessing feature in XmlStringLookup
PJ Fanning created TEXT-224: --- Summary: set SecureProcessing feature in XmlStringLookup Key: TEXT-224 URL: https://issues.apache.org/jira/browse/TEXT-224 Project: Commons Text Issue Type: Task Affects Versions: 1.10.0 Reporter: PJ Fanning https://github.com/apache/commons-text/blob/master/src/main/java/org/apache/commons/text/lookup/XmlStringLookup.java We could set this: xpf.[setFeature|https://www.tabnine.com/code/java/methods/javax.xml.xpath.XPathFactory/setFeature](XMLConstants.FEATURE_SECURE_PROCESSING, Boolean.TRUE); There is more that could be done but this feature would probably be clean enough to roll out - compared to other options like pre-loading the XML using a DocumentBuilder that might be configured to disable External Entities or DTD loading generally. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (COMPRESS-635) switch system.err/system.out printlns to be log4j or slf4j logging
[ https://issues.apache.org/jira/browse/COMPRESS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17641220#comment-17641220 ] PJ Fanning commented on COMPRESS-635: - [~michael-o] I'm neutral about which logging framework to use - slf4j would be fine for me if that was preferred. With there being quite an overlap in the Apache Commons and Apache Logging teams, I thought log4j would be preferred. > switch system.err/system.out printlns to be log4j or slf4j logging > -- > > Key: COMPRESS-635 > URL: https://issues.apache.org/jira/browse/COMPRESS-635 > Project: Commons Compress > Issue Type: Task > Components: Archivers, Compressors >Reporter: PJ Fanning >Priority: Major > > I understand that it is nice for libs not to have transitive dependencies. > The drawback is that users don't get to control where the > system.err/system.out printlns end up - and with a logging framework, they > could also choose to silence logging they don't want to see. > Relates to the logging in COMPRESS-502 - but there are other > system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (COMPRESS-635) switch system.err/system.out printlns to be log4j or slf4j logging
[ https://issues.apache.org/jira/browse/COMPRESS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PJ Fanning updated COMPRESS-635: Summary: switch system.err/system.out printlns to be log4j or slf4j logging (was: switch system.err/system.out printlns to be log4j logging) > switch system.err/system.out printlns to be log4j or slf4j logging > -- > > Key: COMPRESS-635 > URL: https://issues.apache.org/jira/browse/COMPRESS-635 > Project: Commons Compress > Issue Type: Task > Components: Archivers, Compressors >Reporter: PJ Fanning >Priority: Major > > I understand that it is nice for libs not to have transitive dependencies. > The drawback is that users don't get to control where the > system.err/system.out printlns end up - and with a logging framework, they > could also choose to silence logging they don't want to see. > Relates to the logging in COMPRESS-502 - but there are other > system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (COMPRESS-635) switch system.err/system.out printlns to be log4j logging
PJ Fanning created COMPRESS-635: --- Summary: switch system.err/system.out printlns to be log4j logging Key: COMPRESS-635 URL: https://issues.apache.org/jira/browse/COMPRESS-635 Project: Commons Compress Issue Type: Task Components: Archivers, Compressors Reporter: PJ Fanning I understand that it is nice for libs not to have transitive dependencies. The drawback is that users don't get to control where the system.err/system.out printlns end up - and with a logging framework, they could also choose to silence logging they don't want to see. Relates to the logging in COMPRESS-502 - but there are other system.err/system.out printlns too. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CONFIGURATION-821) upgrade snakeyaml to 1.31 due to CVE (optional dependency)
PJ Fanning created CONFIGURATION-821: Summary: upgrade snakeyaml to 1.31 due to CVE (optional dependency) Key: CONFIGURATION-821 URL: https://issues.apache.org/jira/browse/CONFIGURATION-821 Project: Commons Configuration Issue Type: Improvement Reporter: PJ Fanning https://github.com/advisories/GHSA-3mc7-4q67-w48m -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MATH-1638) Add module-info.java into 3.x
[ https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477340#comment-17477340 ] PJ Fanning commented on MATH-1638: -- thanks [~erans] - it looks like an easy uptake for POI when commons-math4 is released - no hurry though > Add module-info.java into 3.x > - > > Key: MATH-1638 > URL: https://issues.apache.org/jira/browse/MATH-1638 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Jan Tošovský >Priority: Major > > When Math3 is used as dependency, the parent project can't be processed by > [jlink|https://docs.oracle.com/javase/9/tools/jlink.htm], which rejects > dependencies with automatic module names. > While module-info is already added to 4.x version, this version is not going > to be released soon. > Would it be possible to fix 3.x version and create a new release? > Thanks! > (Math3 is dependency of Apache POI so entire POI cannot be used as dependency > in my project) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (MATH-1638) Add module-info.java into 3.x
[ https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476921#comment-17476921 ] PJ Fanning edited comment on MATH-1638 at 1/17/22, 5:51 PM: [~erans] this draft PR changes from math3 to math4 and seems to pass all the POI tests - [https://github.com/pjfanning/poi/pull/45] was (Author: pj.fanning): [~erans] this draft PR that changes from math3 to math4 seems to pass all the POI tests - https://github.com/pjfanning/poi/pull/45 > Add module-info.java into 3.x > - > > Key: MATH-1638 > URL: https://issues.apache.org/jira/browse/MATH-1638 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Jan Tošovský >Priority: Major > > When Math3 is used as dependency, the parent project can't be processed by > [jlink|https://docs.oracle.com/javase/9/tools/jlink.htm], which rejects > dependencies with automatic module names. > While module-info is already added to 4.x version, this version is not going > to be released soon. > Would it be possible to fix 3.x version and create a new release? > Thanks! > (Math3 is dependency of Apache POI so entire POI cannot be used as dependency > in my project) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MATH-1638) Add module-info.java into 3.x
[ https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477186#comment-17477186 ] PJ Fanning commented on MATH-1638: -- [~erans] I used the 4.0-SNAPSHOT from https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-math4/4.0-SNAPSHOT/commons-math4-4.0-20210510.174017-767.pom > Add module-info.java into 3.x > - > > Key: MATH-1638 > URL: https://issues.apache.org/jira/browse/MATH-1638 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Jan Tošovský >Priority: Major > > When Math3 is used as dependency, the parent project can't be processed by > [jlink|https://docs.oracle.com/javase/9/tools/jlink.htm], which rejects > dependencies with automatic module names. > While module-info is already added to 4.x version, this version is not going > to be released soon. > Would it be possible to fix 3.x version and create a new release? > Thanks! > (Math3 is dependency of Apache POI so entire POI cannot be used as dependency > in my project) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MATH-1638) Add module-info.java into 3.x
[ https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476921#comment-17476921 ] PJ Fanning commented on MATH-1638: -- [~erans] this draft PR that changes from math3 to math4 seems to pass all the POI tests - https://github.com/pjfanning/poi/pull/45 > Add module-info.java into 3.x > - > > Key: MATH-1638 > URL: https://issues.apache.org/jira/browse/MATH-1638 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Jan Tošovský >Priority: Major > > When Math3 is used as dependency, the parent project can't be processed by > [jlink|https://docs.oracle.com/javase/9/tools/jlink.htm], which rejects > dependencies with automatic module names. > While module-info is already added to 4.x version, this version is not going > to be released soon. > Would it be possible to fix 3.x version and create a new release? > Thanks! > (Math3 is dependency of Apache POI so entire POI cannot be used as dependency > in my project) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MATH-1638) Add module-info.java into 3.x
[
https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476913#comment-17476913
]
PJ Fanning commented on MATH-1638:
--
[~erans] could your team publish a new commons-math4 snapshot - the pom seems a
little out of date, relying on commons-number* projects of version 1.0-SNAPSHOT
when only 1.1-SNAPSHOT seems to be published.
I get errors like:
{code:java}
> Could not resolve all files for configuration ':poi:testRuntimeClasspath'.
> Could not find org.apache.commons:commons-numbers-complex:1.0-SNAPSHOT.
Searched in the following locations:
-
https://repo.maven.apache.org/maven2/org/apache/commons/commons-numbers-complex/1.0-SNAPSHOT/maven-metadata.xml
-
https://repo.maven.apache.org/maven2/org/apache/commons/commons-numbers-complex/1.0-SNAPSHOT/commons-numbers-complex-1.0-SNAPSHOT.pom
-
https://repository.apache.org/content/repositories/releases/org/apache/commons/commons-numbers-complex/1.0-SNAPSHOT/maven-metadata.xml
-
https://repository.apache.org/content/repositories/releases/org/apache/commons/commons-numbers-complex/1.0-SNAPSHOT/commons-numbers-complex-1.0-SNAPSHOT.pom
-
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-numbers-complex/1.0-SNAPSHOT/maven-metadata.xml
-
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-numbers-complex/1.0-SNAPSHOT/commons-numbers-complex-1.0-SNAPSHOT.pom
Required by:
project :poi >
org.apache.commons:commons-math4:4.0-SNAPSHOT:20210510.174017-767
> Could not resolve
org.apache.commons:commons-numbers-complex-streams:1.0-SNAPSHOT.
Required by:
project :poi >
org.apache.commons:commons-math4:4.0-SNAPSHOT:20210510.174017-767
> Could not resolve
org.apache.commons:commons-numbers-complex-streams:1.0-SNAPSHOT.
> Could not parse POM
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-numbers-complex-streams/1.0-SNAPSHOT/commons-numbers-complex-streams-1.0-20200406.133825-171.pom
> Could not find
org.apache.commons:commons-numbers-parent:1.0-SNAPSHOT.
Searched in the following locations:
-
https://repo.maven.apache.org/maven2/org/apache/commons/commons-numbers-parent/1.0-SNAPSHOT/maven-metadata.xml
-
https://repo.maven.apache.org/maven2/org/apache/commons/commons-numbers-parent/1.0-SNAPSHOT/commons-numbers-parent-1.0-SNAPSHOT.pom
-
https://repository.apache.org/content/repositories/releases/org/apache/commons/commons-numbers-parent/1.0-SNAPSHOT/maven-metadata.xml
-
https://repository.apache.org/content/repositories/releases/org/apache/commons/commons-numbers-parent/1.0-SNAPSHOT/commons-numbers-parent-1.0-SNAPSHOT.pom
-
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-numbers-parent/1.0-SNAPSHOT/maven-metadata.xml
-
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-numbers-parent/1.0-SNAPSHOT/commons-numbers-parent-1.0-SNAPSHOT.pom
> Could not find org.apache.commons:commons-numbers-arrays:1.0-SNAPSHOT.
Searched in the following locations:
-
https://repo.maven.apache.org/maven2/org/apache/commons/commons-numbers-arrays/1.0-SNAPSHOT/maven-metadata.xml
-
https://repo.maven.apache.org/maven2/org/apache/commons/commons-numbers-arrays/1.0-SNAPSHOT/commons-numbers-arrays-1.0-SNAPSHOT.pom
-
https://repository.apache.org/content/repositories/releases/org/apache/commons/commons-numbers-arrays/1.0-SNAPSHOT/maven-metadata.xml
-
https://repository.apache.org/content/repositories/releases/org/apache/commons/commons-numbers-arrays/1.0-SNAPSHOT/commons-numbers-arrays-1.0-SNAPSHOT.pom
-
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-numbers-arrays/1.0-SNAPSHOT/maven-metadata.xml
-
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-numbers-arrays/1.0-SNAPSHOT/commons-numbers-arrays-1.0-SNAPSHOT.pom
Required by:
project :poi >
org.apache.commons:commons-math4:4.0-SNAPSHOT:20210510.174017-767
> Could not find org.apache.commons:commons-numbers-angle:1.0-SNAPSHOT.
Searched in the following locations:
-
https://repo.maven.apache.org/maven2/org/apache/commons/commons-numbers-angle/1.0-SNAPSHOT/maven-metadata.xml
-
https://repo.maven.apache.org/maven2/org/apache/commons/commons-numbers-angle/1.0-SNAPSHOT/commons-numbers-angle-1.0-SNAPSHOT.pom
-
https://repository.apache.org/content/repositories/releases/org/apache/commons/commons-numbers-angle/1.0-SNAPSHOT/maven-metadata.xml
-
[jira] [Commented] (MATH-1638) Add module-info.java into 3.x
[ https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476909#comment-17476909 ] PJ Fanning commented on MATH-1638: -- [~erans] the OP is not affiliated with the POI team and I would be happy for you to close this issue. These are some the math3 classes used by POI. import org.apache.commons.math3.util.ArithmeticUtils import org.apache.commons.math3.linear.LUDecomposition; import org.apache.commons.math3.linear.MatrixUtils; import org.apache.commons.math3.linear.RealMatrix; import org.apache.commons.math3.linear.Array2DRowRealMatrix; import org.apache.commons.math3.stat.descriptive.moment.GeometricMean; import org.apache.commons.math3.stat.regression.OLSMultipleLinearRegression; import org.apache.commons.math3.distribution.TDistribution; > Add module-info.java into 3.x > - > > Key: MATH-1638 > URL: https://issues.apache.org/jira/browse/MATH-1638 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Jan Tošovský >Priority: Major > > When Math3 is used as dependency, the parent project can't be processed by > [jlink|https://docs.oracle.com/javase/9/tools/jlink.htm], which rejects > dependencies with automatic module names. > While module-info is already added to 4.x version, this version is not going > to be released soon. > Would it be possible to fix 3.x version and create a new release? > Thanks! > (Math3 is dependency of Apache POI so entire POI cannot be used as dependency > in my project) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (MATH-1638) Add module-info.java into 3.x
[ https://issues.apache.org/jira/browse/MATH-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17476873#comment-17476873 ] PJ Fanning commented on MATH-1638: -- Apache POI team will uptake commons-math v4 when it is released. > Add module-info.java into 3.x > - > > Key: MATH-1638 > URL: https://issues.apache.org/jira/browse/MATH-1638 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Jan Tošovský >Priority: Major > > When Math3 is used as dependency, the parent project can't be processed by > [jlink|https://docs.oracle.com/javase/9/tools/jlink.htm], which rejects > dependencies with automatic module names. > While module-info is already added to 4.x version, this version is not going > to be released soon. > Would it be possible to fix 3.x version and create a new release? > Thanks! > (Math3 is dependency of Apache POI so entire POI cannot be used as dependency > in my project) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IO-732) Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream)
[ https://issues.apache.org/jira/browse/IO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17347698#comment-17347698 ] PJ Fanning commented on IO-732: --- created [https://github.com/apache/commons-io/pull/235] as a draft > Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream) > > > Key: IO-732 > URL: https://issues.apache.org/jira/browse/IO-732 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 2.8.0 >Reporter: PJ Fanning >Priority: Major > > I was thinking of writing this and submitting it but just want to see if > people think it makes sense first. > The idea is to take AbstractByteArrayOutputStream and to replace the byte[] > with char[] (maybe called AbstractCharArrayWriter) and to create an > UnsynchronizedCharArrayWriter that extends it. Could so something similar > with UnsynchronizedByteArrayInputStream - to get an > UnsynchronizedStringReader. > The nice thing about AbstractByteArrayOutputStream is the way it avoids > arraycopy. The existing commons-io StringBuilderWriter still has arraycopy > under the hood (in the java.lang.StringBuilder). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IO-732) Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream)
[ https://issues.apache.org/jira/browse/IO-732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PJ Fanning updated IO-732: -- Description: I was thinking of writing this and submitting it but just want to see if people think it makes sense first. The idea is to take AbstractByteArrayOutputStream and to replace the byte[] with char[] (maybe called AbstractCharArrayWriter) and to create an UnsynchronizedCharArrayWriter that extends it. Could so something similar with UnsynchronizedByteArrayInputStream - to get an UnsynchronizedStringReader. The nice thing about AbstractByteArrayOutputStream is the way it avoids arraycopy. The existing commons-io StringBuilderWriter still has arraycopy under the hood (in the java.lang.StringBuilder). was: I was thinking of writing this and submitting it but just want to see if people think it makes sense first. The idea is to take AbstractByteArrayOutputStream and to replace the byte[] with char[] (maybe called AbstractStringWriter) and to create an UnsynchronizedStringWriter that extends it. Could so something similar with UnsynchronizedByteArrayInputStream - to get an UnsynchronizedStringReader. The nice thing about AbstractByteArrayOutputStream is the way it avoids arraycopy. The existing commons-io StringBuilderWriter still has arraycopy under the hood (in the java.lang.StringBuilder). > Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream) > > > Key: IO-732 > URL: https://issues.apache.org/jira/browse/IO-732 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Affects Versions: 2.8.0 >Reporter: PJ Fanning >Priority: Major > > I was thinking of writing this and submitting it but just want to see if > people think it makes sense first. > The idea is to take AbstractByteArrayOutputStream and to replace the byte[] > with char[] (maybe called AbstractCharArrayWriter) and to create an > UnsynchronizedCharArrayWriter that extends it. Could so something similar > with UnsynchronizedByteArrayInputStream - to get an > UnsynchronizedStringReader. > The nice thing about AbstractByteArrayOutputStream is the way it avoids > arraycopy. The existing commons-io StringBuilderWriter still has arraycopy > under the hood (in the java.lang.StringBuilder). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IO-732) Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream)
PJ Fanning created IO-732: - Summary: Char equivalent of UnsynchronizedByteArrayOutputStream (and InputStream) Key: IO-732 URL: https://issues.apache.org/jira/browse/IO-732 Project: Commons IO Issue Type: New Feature Components: Streams/Writers Affects Versions: 2.8.0 Reporter: PJ Fanning I was thinking of writing this and submitting it but just want to see if people think it makes sense first. The idea is to take AbstractByteArrayOutputStream and to replace the byte[] with char[] (maybe called AbstractStringWriter) and to create an UnsynchronizedStringWriter that extends it. Could so something similar with UnsynchronizedByteArrayInputStream - to get an UnsynchronizedStringReader. The nice thing about AbstractByteArrayOutputStream is the way it avoids arraycopy. The existing commons-io StringBuilderWriter still has arraycopy under the hood (in the java.lang.StringBuilder). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (COMPRESS-445) Zip Bomb Detection
PJ Fanning created COMPRESS-445: --- Summary: Zip Bomb Detection Key: COMPRESS-445 URL: https://issues.apache.org/jira/browse/COMPRESS-445 Project: Commons Compress Issue Type: Improvement Components: Archivers Reporter: PJ Fanning It would be a nice feature if ZipFile had support for detecting Zip Bombs. Apache Poi has an implementation based on the java util ZipFile but this relies on Reflection and changes in Java 10 mean this code will not work in that version. [https://github.com/apache/poi/blob/trunk/src/ooxml/java/org/apache/poi/openxml4j/util/ZipSecureFile.java] One option would be to add equivalent change support in commons-compress and for Poi to use the commons version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
