[GitHub] [commons-geometry] asfgit merged pull request #83: GEOMETRY-95: Adding BSP tree tutorial
asfgit merged pull request #83: URL: https://github.com/apache/commons-geometry/pull/83 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (CSV-257) Updating from 1.6 to 1.7 breaks
[
https://issues.apache.org/jira/browse/CSV-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150558#comment-17150558
]
Holger Brandl edited comment on CSV-257 at 7/2/20, 9:08 PM:
I think that the commons-csv should not be opinionated concerning the question
if an empty header makes sense or not. It should parse it (if the structure is
legit csv) and leave this decision to the user.
It's a common pattern to have an empty header for the first column containing
the row number/index. E.g. see official examples such as
[https://jetbrains.bintray.com/lets-plot/mpg.csv]
was (Author: holgerbrandl):
I think that the commons-csv should not be opinionated concerning the question
if an empty header makes sense or not. It should parse it (if the structure is
legit csv) and leave this decision to the user.
> Updating from 1.6 to 1.7 breaks
> ---
>
> Key: CSV-257
> URL: https://issues.apache.org/jira/browse/CSV-257
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.7
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade commons csv from 1.6 to the latest version 1.7. The
> following code breaks.
> {code:java}
> public class Demo {
> @Test
> public void TestCSV(){
> try {
> InputStream testInput = new
> ByteArrayInputStream(",".getBytes(StandardCharsets.UTF_8));
> Reader reader = new InputStreamReader(testInput);
> char character = ",".charAt(0);
> CSVFormat format =
> CSVFormat.RFC4180.withDelimiter(character).withFirstRecordAsHeader().withIgnoreSurroundingSpaces();
> CSVParser parser = new CSVParser(reader, format);
> } catch (Exception e) {
> System.out.println("!!!");
> assertEquals("java.lang.IllegalArgumentException: The
> header contains a duplicate name: \"\" in [, ]", e.toString());
> }
> }
> }
> {code}
> The test should pass, but it failed with error:
> {code:java}
> org.junit.ComparisonFailure: expected:<...lArgumentException: [The header
> contains a duplicate name: ""] in [, ]> but was:<...lArgumentException: [A
> header name is missing] in [, ]>
> at org.junit.Assert.assertEquals(Assert.java:115)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at Demo.TestCSV(Demo.java:31)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-geometry] asfgit merged pull request #82: GEOMETRY-63: Fixes for various SonarQube and IDE warnings
asfgit merged pull request #82: URL: https://github.com/apache/commons-geometry/pull/82 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (CSV-257) Updating from 1.6 to 1.7 breaks
[
https://issues.apache.org/jira/browse/CSV-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150558#comment-17150558
]
Holger Brandl commented on CSV-257:
---
I think that the commons-csv should not be opinionated concerning the question
if an empty header makes sense or not. It should parse it (if the structure is
legit csv) and leave this decision to the user.
> Updating from 1.6 to 1.7 breaks
> ---
>
> Key: CSV-257
> URL: https://issues.apache.org/jira/browse/CSV-257
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.7
>Reporter: xia0c
>Priority: Major
>
> When I try to upgrade commons csv from 1.6 to the latest version 1.7. The
> following code breaks.
> {code:java}
> public class Demo {
> @Test
> public void TestCSV(){
> try {
> InputStream testInput = new
> ByteArrayInputStream(",".getBytes(StandardCharsets.UTF_8));
> Reader reader = new InputStreamReader(testInput);
> char character = ",".charAt(0);
> CSVFormat format =
> CSVFormat.RFC4180.withDelimiter(character).withFirstRecordAsHeader().withIgnoreSurroundingSpaces();
> CSVParser parser = new CSVParser(reader, format);
> } catch (Exception e) {
> System.out.println("!!!");
> assertEquals("java.lang.IllegalArgumentException: The
> header contains a duplicate name: \"\" in [, ]", e.toString());
> }
> }
> }
> {code}
> The test should pass, but it failed with error:
> {code:java}
> org.junit.ComparisonFailure: expected:<...lArgumentException: [The header
> contains a duplicate name: ""] in [, ]> but was:<...lArgumentException: [A
> header name is missing] in [, ]>
> at org.junit.Assert.assertEquals(Assert.java:115)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at Demo.TestCSV(Demo.java:31)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-geometry] darkma773r opened a new pull request #83: GEOMETRY-95: Adding BSP tree tutorial
darkma773r opened a new pull request #83: URL: https://github.com/apache/commons-geometry/pull/83 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150398#comment-17150398
]
Enrico Olivelli commented on NET-408:
-
I have read all of the comments from the past.
It looks like now BC is able to resume the session
[https://www.bouncycastle.org/releasenotes.html]
I am not a TLS expert, is anyone able to try again with BC ?
As this is mostly a Java Runtime issue I feel we won't be able to support
session resumption without a Java release.
So we would need some Java engineer to work on it and then a Java release, and
then users will have to adopt the most recent Java versionI see it hard to
happen in the near future.
But it looks like that this requirement of session resumption is more and more
used by FTPs servers administrators
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-507) Commons Compress cannot be built with JDK14 due to Pack200 removal
[
https://issues.apache.org/jira/browse/COMPRESS-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17150065#comment-17150065
]
Lőrinc Pap commented on COMPRESS-507:
-
We're using {{Proguard}} for bytecode obfuscation, parsing existing class
references: it fails to find {{java.util.jar.Pack200.}}
> Commons Compress cannot be built with JDK14 due to Pack200 removal
> --
>
> Key: COMPRESS-507
> URL: https://issues.apache.org/jira/browse/COMPRESS-507
> Project: Commons Compress
> Issue Type: Bug
> Components: Build, Compressors
>Affects Versions: 1.20
>Reporter: Vincent Privat
>Priority: Major
> Fix For: 1.21
>
>
> Oracle dropped Pack200 in JDK14 as per
> [https://bugs.openjdk.java.net/browse/JDK-8232022]
> Someone expressed his will to maintain Pack200 here:
> [https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/003979.html]
> [https://github.com/pfirmstone/Pack200-ex-openjdk]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
