[jira] [Resolved] (MATH-798) PolynomialFitter.fit() stalls
[ https://issues.apache.org/jira/browse/MATH-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-798. - Resolution: Fixed Fix Version/s: 3.1 Changes performed in revision 1357353. The unit test "testMath798" is now in "PolynomialFitterTest". > PolynomialFitter.fit() stalls > - > > Key: MATH-798 > URL: https://issues.apache.org/jira/browse/MATH-798 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: Mac OS 10.6 and Win XP >Reporter: Kurt Pernstich > Fix For: 3.1 > > Attachments: PolynomialFitterTest.java > > > Hi, in certain cases I ran into the problem that the PolynomialFitter.fit() > method stalls, meaning that it does not return, nor throw an Exception (even > if it runs for 90 min). Is there a way to tell the PolynomialFitter to > iterate only N-times to ensure that my program does not stall? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-462) FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have several different IP
[ https://issues.apache.org/jira/browse/NET-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bogdan Drozdowski updated NET-462: -- Attachment: ftp-bindlocal.diff The attached patch fixes this by adding a new field in FTPClient. By calling setPassiveLocalIPAddress(), you can set the local address to bind to. The field will be used in the same place as in your code (but it is a separate value from what getHostAddress returns). In the meantime, you can create and install your own SocketFactory in the FTPClient. You can take DefaultSocketFactory class as an example and make you own factory, which will create sockes already bound to your local address. This will work even with the older versions of Commons-Net. > FTPClient in PASSIVE_LOCAL_DATA_CONNECTION_MODE cannot work when host have > several different IP > --- > > Key: NET-462 > URL: https://issues.apache.org/jira/browse/NET-462 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 3.1 > Environment: All OS,for example linux or windows and so on >Reporter: Junsheng Chen >Priority: Minor > Labels: ActiveIp, FTPClient, PASSIVE_LOCAL_DATA_CONNECTION_MODE > Fix For: 3.2 > > Attachments: ftp-bindlocal.diff > > Original Estimate: 24h > Remaining Estimate: 24h > > When host have several different IP and client setting to > PASSIVE_LOCAL_DATA_CONNECTION_MODE，_openDataConnection_ creating socket may > use the unexpected ip。 > For example, The host have two Ips, one for intra and the another for extern, > only the extern one can be connect with the outside。But when in > PASSIVE_LOCAL_DATA_CONNECTION_MODE, FTPClient may be select the intra Ip, So > it didn't work。 > So I change code like this, it can work normally by the specific ip. > Code: > In FTPClient._openDataConnection_(String command, String arg)，line 761 change > as bellow: > socket = _socketFactory_.createSocket(); > > // add begin > // local as client, transfer data must use the appointed local host > socket.bind(new InetSocketAddress(getHostAddress(), 0)); > // add end > After log in success,User can set the ip which he want to use by call the > method in FTPClient: > setActiveExternalIPAddress(String ip); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-468) Request for native support for socks proxy routing with Commons net FTP
[ https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406621#comment-13406621 ] Gary D. Gregory commented on NET-468: - Well, it's up to you. If I can't easily apply a patch with Eclipse's SVN UI, I won't bother. Got lots to do, sorry. > Request for native support for socks proxy routing with Commons net FTP > --- > > Key: NET-468 > URL: https://issues.apache.org/jira/browse/NET-468 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 1.4, 2.0, 3.0.1, 3.1 > Environment: We use commons net in out products for all > communication to an FTP server. OS : All. No other environment specifications. >Reporter: Ramya Rajendiran > Attachments: sockclient-proxy3.diff > > > Commons net currently does not natively support connection to an FTP server > via a socks proxy. The only way of achieving this would be to work at the > socket level as observed here > http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM > properties socksProxyPort and socksProxyPortHost) > However, a major side effect of this all connections on this JVM will go > through the socks proxy since this setting is at the JVM level. This is > sometimes undesirable as the business requirements are such that only certain > applications on the JVM need to go through the socks proxy. There are no > existing workarounds to conditionally prevent other applications to not be > routed through the socks proxy. This makes our application which consumes the > commons net unusable for such businesses. > Providing native support for socks proxy with commons net for FTP, will go a > long way in supporting such common scenarios and business continuity. > Therefore raising this enhancement request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP
[ https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bogdan Drozdowski updated NET-468: -- Attachment: (was: sockclient-proxy2.diff) > Request for native support for socks proxy routing with Commons net FTP > --- > > Key: NET-468 > URL: https://issues.apache.org/jira/browse/NET-468 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 1.4, 2.0, 3.0.1, 3.1 > Environment: We use commons net in out products for all > communication to an FTP server. OS : All. No other environment specifications. >Reporter: Ramya Rajendiran > Attachments: sockclient-proxy3.diff > > > Commons net currently does not natively support connection to an FTP server > via a socks proxy. The only way of achieving this would be to work at the > socket level as observed here > http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM > properties socksProxyPort and socksProxyPortHost) > However, a major side effect of this all connections on this JVM will go > through the socks proxy since this setting is at the JVM level. This is > sometimes undesirable as the business requirements are such that only certain > applications on the JVM need to go through the socks proxy. There are no > existing workarounds to conditionally prevent other applications to not be > routed through the socks proxy. This makes our application which consumes the > commons net unusable for such businesses. > Providing native support for socks proxy with commons net for FTP, will go a > long way in supporting such common scenarios and business continuity. > Therefore raising this enhancement request. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-468) Request for native support for socks proxy routing with Commons net FTP
[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Drozdowski updated NET-468:
--
Attachment: sockclient-proxy3.diff
No, I didn't use the SVN diff command to create the patch. I prefer to keep my
working copy clean, so I copy the files I wish to modify somewhere else and
perform a "diff -buraN" command. To apply the patch, use the "patch" utility,
common in many Linux distributions. The command will be something similar to
{code}patch -F20 -p0 < /path/to/sockclient-proxy2.diff{code}
(run in the directory that contains the "src" directory). If that's a problem,
I can use "svn diff".
The previous patch had an error - the test wasn't in src/test. Use the third
version I've just attached.
> Request for native support for socks proxy routing with Commons net FTP
> ---
>
> Key: NET-468
> URL: https://issues.apache.org/jira/browse/NET-468
> Project: Commons Net
> Issue Type: Improvement
> Components: FTP
>Affects Versions: 1.4, 2.0, 3.0.1, 3.1
> Environment: We use commons net in out products for all
> communication to an FTP server. OS : All. No other environment specifications.
>Reporter: Ramya Rajendiran
> Attachments: sockclient-proxy3.diff
>
>
> Commons net currently does not natively support connection to an FTP server
> via a socks proxy. The only way of achieving this would be to work at the
> socket level as observed here
> http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM
> properties socksProxyPort and socksProxyPortHost)
> However, a major side effect of this all connections on this JVM will go
> through the socks proxy since this setting is at the JVM level. This is
> sometimes undesirable as the business requirements are such that only certain
> applications on the JVM need to go through the socks proxy. There are no
> existing workarounds to conditionally prevent other applications to not be
> routed through the socks proxy. This makes our application which consumes the
> commons net unusable for such businesses.
> Providing native support for socks proxy with commons net for FTP, will go a
> long way in supporting such common scenarios and business continuity.
> Therefore raising this enhancement request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-798) PolynomialFitter.fit() stalls
[ https://issues.apache.org/jira/browse/MATH-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406491#comment-13406491 ] Gilles commented on MATH-798: - Your use-case had already been included in the unit test suite (albeit in the "CurveFitterTest" class because I initially wanted to remove the "PolynomialFitter" class). MATH-799 discusses that the problem you reported here happens because the default tolerances were much too small. This has been solved (cf. unit test method "testMath798" in "CurveFitterTest"). However, since the mistake of setting the tolerances at too low values could still happen, I'm going to add a new (overridden) method in "PolynomialFitter", where you can explicitly set the number of allowed evaluations of the polynomial during the fit process. This will make it fail early instead of running "forever" (not really: the default number of evaluation is "Integer.MAX_VALUE"). > PolynomialFitter.fit() stalls > - > > Key: MATH-798 > URL: https://issues.apache.org/jira/browse/MATH-798 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 > Environment: Mac OS 10.6 and Win XP >Reporter: Kurt Pernstich > Attachments: PolynomialFitterTest.java > > > Hi, in certain cases I ran into the problem that the PolynomialFitter.fit() > method stalls, meaning that it does not return, nor throw an Exception (even > if it runs for 90 min). Is there a way to tell the PolynomialFitter to > iterate only N-times to ensure that my program does not stall? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-468) Request for native support for socks proxy routing with Commons net FTP
[
https://issues.apache.org/jira/browse/NET-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406450#comment-13406450
]
Gary D. Gregory commented on NET-468:
-
Hello,
I cannot apply the patch. Did you use SVN diff to create the patch?
The format looks odd:
I see:
{noformat}
--- src/main/java/org/apache/commons/net/SocketClient.java 2012-04-24
17:30:45.596176007 +0200
+++ ../../org/apache/commons/net/SocketClient.java 2012-07-02
18:21:00.287784277 +0200
...
{noformat}
and expect:
{noformat}
Index: src/main/java/org/apache/commons/net/SocketClient.java
===
--- src/main/java/org/apache/commons/net/SocketClient.java (revision
1357226)
+++ src/main/java/org/apache/commons/net/SocketClient.java (working copy)
...
{noformat}
Thank you,
Gary
> Request for native support for socks proxy routing with Commons net FTP
> ---
>
> Key: NET-468
> URL: https://issues.apache.org/jira/browse/NET-468
> Project: Commons Net
> Issue Type: Improvement
> Components: FTP
>Affects Versions: 1.4, 2.0, 3.0.1, 3.1
> Environment: We use commons net in out products for all
> communication to an FTP server. OS : All. No other environment specifications.
>Reporter: Ramya Rajendiran
> Attachments: sockclient-proxy2.diff
>
>
> Commons net currently does not natively support connection to an FTP server
> via a socks proxy. The only way of achieving this would be to work at the
> socket level as observed here
> http://wiki.apache.org/commons/Net/FrequentlyAskedQuestions. (by setting JVM
> properties socksProxyPort and socksProxyPortHost)
> However, a major side effect of this all connections on this JVM will go
> through the socks proxy since this setting is at the JVM level. This is
> sometimes undesirable as the business requirements are such that only certain
> applications on the JVM need to go through the socks proxy. There are no
> existing workarounds to conditionally prevent other applications to not be
> routed through the socks proxy. This makes our application which consumes the
> commons net unusable for such businesses.
> Providing native support for socks proxy with commons net for FTP, will go a
> long way in supporting such common scenarios and business continuity.
> Therefore raising this enhancement request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-193) java.io.IOException: This archives contains unclosed entries.
Shishir goswami created COMPRESS-193:
Summary: java.io.IOException: This archives contains unclosed
entries.
Key: COMPRESS-193
URL: https://issues.apache.org/jira/browse/COMPRESS-193
Project: Commons Compress
Issue Type: Bug
Environment: Windows Server 2008 R2
Reporter: Shishir goswami
I am getting java.io.IOException: This archives contains unclosed entries.Below
is the code. Any help is much appreciated
final File output = new File("c:\\testdata", "shishir.zip");
final File file1 = new File ("C:\\testdata\test1.xml");
final File file2 = new File ("C:\\testdata\test2.xml");
final OutputStream out = new FileOutputStream(output);
ArchiveOutputStream os = null;
FileInputStream input1=null;
FileInputStream input2=null;
try {
os = new ArchiveStreamFactory()
.createArchiveOutputStream("zip", out);
os.putArchiveEntry(new ZipArchiveEntry("testdata\test1.xml"));
input1 = new FileInputStream(file1);
IOUtils.copy(input1, os);
input1.close();
os.closeArchiveEntry();
input2 = new FileInputStream(file2);
input2.close();
os.putArchiveEntry(new ZipArchiveEntry("testdata\test2.xml"));
IOUtils.copy(input2, os);
os.closeArchiveEntry();
os.finish();
} finally {
if (os != null) {
os.close();
}else if (out != null) {
out.close();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-811) Improve event detection by selecting g function slope
Yannick TANGUY created MATH-811: --- Summary: Improve event detection by selecting g function slope Key: MATH-811 URL: https://issues.apache.org/jira/browse/MATH-811 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Yannick TANGUY We would like to select g function slope in CommonsMath event detection feature. This would improve event detection for the final user (the possibility to ignore some events, and less computation time) and also correct a bug found while using OREKIT (see https://www.orekit.org/forge/issues/104) in our applications. The modification consists in adding a method (getSlopeSelection() : int) in EventHandler, and modifying one conditionnal in the method evaluateStep (class EventState). We can provide modified code and unitary tests for this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
