[jira] [Commented] (NET-642) using execPROT on FTPSClients with Proxy Settings removes Proxy Settings
[ https://issues.apache.org/jira/browse/NET-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121397#comment-16121397 ] Johannes Frank commented on NET-642: Setting it to critical because we already have two customers now that can't switch from FTP to FTPS due to the need of going through a Proxy. > using execPROT on FTPSClients with Proxy Settings removes Proxy Settings > > > Key: NET-642 > URL: https://issues.apache.org/jira/browse/NET-642 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Java 1.8.0_112 > Linux 64bit >Reporter: Johannes Frank >Priority: Critical > > In Reference to https://issues.apache.org/jira/browse/NET-578 > I'm trying to establish an FTPS Connection via a HTTP Proxy. The Control > Connection is properly established, however the Moment I do execPROT the > Proxy settings are resetted by call to setSocketFactory(new > FTPSSocketFactory(context)); in FTPSClient.java:534. > This causes FTPSClients with a call to execPROT to actually ignore the proxy > settings and attempt to contact the FTPS Server directly for data connections. > Since we are required to use PROT P this is currently blocking our feature > for FTPS Connections via HTTP proxy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (NET-642) using execPROT on FTPSClients with Proxy Settings removes Proxy Settings
[ https://issues.apache.org/jira/browse/NET-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Johannes Frank updated NET-642: --- Priority: Critical (was: Major) > using execPROT on FTPSClients with Proxy Settings removes Proxy Settings > > > Key: NET-642 > URL: https://issues.apache.org/jira/browse/NET-642 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Java 1.8.0_112 > Linux 64bit >Reporter: Johannes Frank >Priority: Critical > > In Reference to https://issues.apache.org/jira/browse/NET-578 > I'm trying to establish an FTPS Connection via a HTTP Proxy. The Control > Connection is properly established, however the Moment I do execPROT the > Proxy settings are resetted by call to setSocketFactory(new > FTPSSocketFactory(context)); in FTPSClient.java:534. > This causes FTPSClients with a call to execPROT to actually ignore the proxy > settings and attempt to contact the FTPS Server directly for data connections. > Since we are required to use PROT P this is currently blocking our feature > for FTPS Connections via HTTP proxy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (LANG-1348) StackOverflowError on TypeUtils.toString(...) for a generic return type of Enum.valueOf
[
https://issues.apache.org/jira/browse/LANG-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Ovchinnikov updated LANG-1348:
-
Environment: Java 8 update 144 (was: Java 8 update 151)
> StackOverflowError on TypeUtils.toString(...) for a generic return type of
> Enum.valueOf
> ---
>
> Key: LANG-1348
> URL: https://issues.apache.org/jira/browse/LANG-1348
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.6
> Environment: Java 8 update 144
>Reporter: Dmitry Ovchinnikov
>Priority: Critical
>
> The following code
> {code:java}
> final Method method = Enum.class.getMethod("valueOf", Class.class,
> String.class);
> final String typeText = TypeUtils.toString(method.getGenericReturnType());
> {code}
> throws the following
> {code:none}
> Exception in thread "main" java.lang.StackOverflowError
> at
> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.getRawType(ParameterizedTypeImpl.java:126)
> at
> sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl.getRawType(ParameterizedTypeImpl.java:40)
> at
> org.apache.commons.lang3.reflect.TypeUtils.parameterizedTypeToString(TypeUtils.java:1790)
> at
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1666)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
> at
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
> at
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
> at
> org.apache.commons.lang3.reflect.TypeUtils.parameterizedTypeToString(TypeUtils.java:1803)
> at
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1666)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
> at
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
> at
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
> at
> org.apache.commons.lang3.reflect.TypeUtils.parameterizedTypeToString(TypeUtils.java:1803)
> at
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1666)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
> at
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
> at
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
> at
> org.apache.commons.lang3.reflect.TypeUtils.parameterizedTypeToString(TypeUtils.java:1803)
> at
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1666)
> at
> org.apache.commons.lang3.reflect.TypeUtils.appendAllTo(TypeUtils.java:1846)
> at
> org.apache.commons.lang3.reflect.TypeUtils.typeVariableToString(TypeUtils.java:1775)
> at
> org.apache.commons.lang3.reflect.TypeUtils.toString(TypeUtils.java:1672)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the Line Ending
Nitin Mahendru created CSV-214: -- Summary: Adding a placeholder in the Lexer and CSV parser to store the Line Ending Key: CSV-214 URL: https://issues.apache.org/jira/browse/CSV-214 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Nitin Mahendru Priority: Trivial Fix For: Discussion Hi All, In my use-case , I have to read a CSV file, Mangle some columns and then write out a new csv file with those mangled columns. I have gone through the parser code and I have found no usable way of getting the line ending information from the CSVParser object. The function readEndOfLine just consumes End of line whether it is CRLF or LF. Now that problem is that when I am writing my file back using the CSVPrinter, I need to know what line ending my input file was. I could write an external function to do that. A better way would be to store that information in the CSVParser object and just use it. To do that I am just saving the state in a variable and exposing that using a getter. I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the Line Ending
[ https://issues.apache.org/jira/browse/CSV-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122232#comment-16122232 ] Gary Gregory commented on CSV-214: -- What happens when one line ends with CR and another with CRLF? > Adding a placeholder in the Lexer and CSV parser to store the Line Ending > - > > Key: CSV-214 > URL: https://issues.apache.org/jira/browse/CSV-214 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Priority: Trivial > Fix For: Discussion > > Original Estimate: 24h > Remaining Estimate: 24h > > Hi All, > > In my use-case , I have to read a CSV file, Mangle some columns and then > write out a new csv file with those mangled columns. > I have gone through the parser code and I have found no usable way of getting > the line ending information from the CSVParser object. The function > readEndOfLine just consumes End of line whether it is CRLF or LF. > Now that problem is that when I am writing my file back using the CSVPrinter, > I need to know what line ending my input file was. I could write an external > function to do that. A better way would be to store that information in the > CSVParser object and just use it. > To do that I am just saving the state in a variable and exposing that using a > getter. > I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (NET-642) using execPROT on FTPSClients with Proxy Settings removes Proxy Settings
[ https://issues.apache.org/jira/browse/NET-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122295#comment-16122295 ] Gary Gregory commented on NET-642: -- Hi Johannes, Thank you for your report. Feel free to create a PR on GitHub with a unit test if you can. Gary > using execPROT on FTPSClients with Proxy Settings removes Proxy Settings > > > Key: NET-642 > URL: https://issues.apache.org/jira/browse/NET-642 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 3.6 > Environment: Java 1.8.0_112 > Linux 64bit >Reporter: Johannes Frank >Priority: Critical > > In Reference to https://issues.apache.org/jira/browse/NET-578 > I'm trying to establish an FTPS Connection via a HTTP Proxy. The Control > Connection is properly established, however the Moment I do execPROT the > Proxy settings are resetted by call to setSocketFactory(new > FTPSSocketFactory(context)); in FTPSClient.java:534. > This causes FTPSClients with a call to execPROT to actually ignore the proxy > settings and attempt to contact the FTPS Server directly for data connections. > Since we are required to use PROT P this is currently blocking our feature > for FTPS Connections via HTTP proxy. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the Line Ending
[ https://issues.apache.org/jira/browse/CSV-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122354#comment-16122354 ] Nitin Mahendru commented on CSV-214: That would mean a badly formatted file which needs to be corrected in the first place. Although what would happen is that the line ending in the first line will be considered as absolute and final. > Adding a placeholder in the Lexer and CSV parser to store the Line Ending > - > > Key: CSV-214 > URL: https://issues.apache.org/jira/browse/CSV-214 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Priority: Trivial > Fix For: Discussion > > Original Estimate: 24h > Remaining Estimate: 24h > > Hi All, > > In my use-case , I have to read a CSV file, Mangle some columns and then > write out a new csv file with those mangled columns. > I have gone through the parser code and I have found no usable way of getting > the line ending information from the CSVParser object. The function > readEndOfLine just consumes End of line whether it is CRLF or LF. > Now that problem is that when I am writing my file back using the CSVPrinter, > I need to know what line ending my input file was. I could write an external > function to do that. A better way would be to store that information in the > CSVParser object and just use it. > To do that I am just saving the state in a variable and exposing that using a > getter. > I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the Line Ending
[ https://issues.apache.org/jira/browse/CSV-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122360#comment-16122360 ] Nitin Mahendru commented on CSV-214: pull request raised. > Adding a placeholder in the Lexer and CSV parser to store the Line Ending > - > > Key: CSV-214 > URL: https://issues.apache.org/jira/browse/CSV-214 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Priority: Trivial > Fix For: Discussion > > Original Estimate: 24h > Remaining Estimate: 24h > > Hi All, > > In my use-case , I have to read a CSV file, Mangle some columns and then > write out a new csv file with those mangled columns. > I have gone through the parser code and I have found no usable way of getting > the line ending information from the CSVParser object. The function > readEndOfLine just consumes End of line whether it is CRLF or LF. > Now that problem is that when I am writing my file back using the CSVPrinter, > I need to know what line ending my input file was. I could write an external > function to do that. A better way would be to store that information in the > CSVParser object and just use it. > To do that I am just saving the state in a variable and exposing that using a > getter. > I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CSV-214) Adding a placeholder in the Lexer and CSV parser to store the Line Ending
[ https://issues.apache.org/jira/browse/CSV-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-214: - Assignee: Gary Gregory > Adding a placeholder in the Lexer and CSV parser to store the Line Ending > - > > Key: CSV-214 > URL: https://issues.apache.org/jira/browse/CSV-214 > Project: Commons CSV > Issue Type: Improvement > Components: Parser >Reporter: Nitin Mahendru >Assignee: Gary Gregory >Priority: Trivial > Fix For: Discussion > > Original Estimate: 24h > Remaining Estimate: 24h > > Hi All, > > In my use-case , I have to read a CSV file, Mangle some columns and then > write out a new csv file with those mangled columns. > I have gone through the parser code and I have found no usable way of getting > the line ending information from the CSVParser object. The function > readEndOfLine just consumes End of line whether it is CRLF or LF. > Now that problem is that when I am writing my file back using the CSVPrinter, > I need to know what line ending my input file was. I could write an external > function to do that. A better way would be to store that information in the > CSVParser object and just use it. > To do that I am just saving the state in a variable and exposing that using a > getter. > I have done some basic testing. and Submitting a pull request regarding that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IO-546) ClosedOutputStream#flush should throw
[
https://issues.apache.org/jira/browse/IO-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Celaya updated IO-546:
Attachment: IO-546.patch
Went ahead and generated a patch for this change with the relevant test case.
> ClosedOutputStream#flush should throw
> -
>
> Key: IO-546
> URL: https://issues.apache.org/jira/browse/IO-546
> Project: Commons IO
> Issue Type: Improvement
> Components: Streams/Writers
>Reporter: Tomas Celaya
>Priority: Minor
> Attachments: IO-546.patch
>
>
> While debugging an issue involving usage of {{CloseShieldOutputStream}} I
> discovered that {{ClosedOutputStream#flush}} is not overridden and will
> silently succeed. Not sure how much of a breaking change this might be but I
> think it makes more sense for {{ClosedOutputStream#flush}} to throw. This is
> only really meaningful in contexts where multiple streams are being chained
> together and some of the streams before {{CloseShieldOutputStream}} perform
> buffering, but it would make behavior more consistent for these more complex
> use-cases.
> No patches are included because I'm interested in hearing what the opinion
> would be on this issue. I can provide a patch if this seems like desired
> behavior.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
