[jira] Commented: (NET-363) Can't connect to a server behind firewall in passive mode
[ https://issues.apache.org/jira/browse/NET-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002901#comment-13002901 ] Sebb commented on NET-363: -- In NET-296 I wrote: bq. But can a local address ever be valid if the original address was not local? I suspect not. If this is true, then the code that handles the PASV reply can set __passiveHost accordingly, and there would be no need to use the try/catch (or cache the result in __useRemoteHost). > Can't connect to a server behind firewall in passive mode > - > > Key: NET-363 > URL: https://issues.apache.org/jira/browse/NET-363 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.2 > Environment: Windows Client with Zos mainframe server behind a > firewall. However I think any client/server will demonstrate the issue as > long as the server is behind a firewall. >Reporter: daniel damon >Priority: Blocker > > When the FTP server is behind a firewall, FTPClient can connect, but it > cannot transfer data. This is because the FTP server provides it's own > address instead of the firewall address to make the connection. I have > confirmed the problem by hacking a copy of FTPClient to set the __passiveHost > to the appropriate internet address. With this hack, I can transfer data. > Perhaps the FTP server could be configured differently to fix the issue. > Unfortunately, I do not have access to the server configuration. I do know > that the commercial product IpswitchFtp does deal with the issue as this > extract from it's log shows: > > PASV > 227 Entering Passive Mode (192,168,13,11,195,129) > connecting data channel to 192.168.13.11:195,129(50049) > Substituting connection address 159.106.121.79 for private address > 192.168.13.11 from PASV > data channel connected to 159.106.121.79:195,129(50049) > LIST > 125 List started OK > transferred 4157 bytes in 0.078 seconds, 425.688 kbps ( 53.211 kBps), > transfer succeeded. > 250 List completed successfully. > QUIT > > I can take a shot at a fix if you want. I'll set some timeout, and if that > fails, I'll use the original address -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-296) java.net.SocketException: Operation timed out error while entering Passive mode
[
https://issues.apache.org/jira/browse/NET-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-296.
--
Resolution: Duplicate
I see you have opened NET-363, so closing this as a duplicate
> java.net.SocketException: Operation timed out error while entering Passive
> mode
> ---
>
> Key: NET-296
> URL: https://issues.apache.org/jira/browse/NET-296
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP, JDK 1.5.0_15, commons-net-2.0-jdk14.jar
>Reporter: Hariprasad K S
>Priority: Blocker
>
> Hi,
> I am getting the following error while trying to connect to the FTP
> (Explicit).
> java.net.SocketException: Operation timed out: connect:could be due to
> invalid address.
> I am facing this error when i am running the code from the client machine
> which is in different domain...If i run the same code in the domain where ftp
> exists..it works fine without any issue...below is my code and the trace
> logPls help.
> FTPSClient client = new FTPSClient("TLS",false);
> client.addProtocolCommandListener(new PrintCommandListener(new
> PrintWriter(System.out)));
> boolean _ftp_login = false;
>
> try {
> String[] hname = ftpurl.split("//");
> client.setAuthValue("TLS");
> client.setRemoteVerificationEnabled(false);
> client.connect("ftp.kotaklifeinsurance.com",22);
>
> int reply = client.getReplyCode();
> client.execPBSZ(0);
> client.execPROT("P");
>
> if (!FTPReply.isPositiveCompletion(reply)) {
> client.disconnect();
> System.out.println("openFTPClient(): FTP server refused
> connection.");
> throw new Exception("FTP server refused connection.");
> } else {
> try {
> _ftp_login = client.login(userID, password);
> } catch (Exception e) {
> throw e;
> }
> if (_ftp_login) {
>
> client.enterLocalPassiveMode();
>
> if (client.printWorkingDirectory() == null)
> throw new Exception("Current working directory
> returned is null");
> client.changeWorkingDirectory("/XYZ/");
> fis = new FileInputStream(localfile);
> ins = (InputStream)fis;
> boolean flag = client.storeFile(filename,ins);
> System.out.println("File saved to FTP : "+flag);
> Error Trace :
> 220 Unauthorized Access Prohibited.
> AUTH TLS
> 234 AUTH command ok. Expecting TLS Negotiation.
> PBSZ 0
> 200 PBSZ command successful.
> PROT P
> 200 PROT command successful.
> USER userid
> 331 Password required for userid.
> PASS password
> 230 User logged in.
> PWD
> 257 "/" is current directory.
> CWD /XYZ/
> 250 CWD command successful.
> PWD
> 257 "/XYZ" is current directory.
> TYPE A
> 200 Type set to A.
> MODE I
> 501 'MODE I': parameter not understood.
> STRU F
> 200 STRU F ok.
> PASV
> 227 Entering Passive Mode (192,168,201,220,195,108).
> java.net.SocketException: Operation timed out: connect:could be due to
> invalid address
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:331)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:196)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:183)
> at java.net.Socket.connect(Socket.java:478)
> at java.net.Socket.connect(Socket.java:428)
> at java.net.Socket.(Socket.java:335)
> at java.net.Socket.(Socket.java:150)
> at com.ibm.jsse.bs.(Unknown Source)
> at com.ibm.jsse.JSSESocketFactory.createSocket(Unknown Source)
> at
> org.apache.commons.net.ftp.FTPSSocketFactory.createSocket(FTPSSocketFactory.java:48)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
> at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:374)
> at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:1379)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (NET-296) java.net.SocketException: Operation timed out error while entering Passive mode
[
https://issues.apache.org/jira/browse/NET-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb reopened NET-296:
--
I see. Sounds like a good plan.
A local address such as in the reply:
227 Entering Passive Mode (192,168,201,220,195,108)
may actually be valid if the original address was local.
But can a local address ever be valid if the original address was not local? I
suspect not.
In which case, there is no need for the code to try connecting, it can just use
the original address + reply port. (or if original was local, continue as
usual).
==
I assume the server you are connecting to is not publicly accessible?
Would you be able to help with testing any changes?
> java.net.SocketException: Operation timed out error while entering Passive
> mode
> ---
>
> Key: NET-296
> URL: https://issues.apache.org/jira/browse/NET-296
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP, JDK 1.5.0_15, commons-net-2.0-jdk14.jar
>Reporter: Hariprasad K S
>Priority: Blocker
>
> Hi,
> I am getting the following error while trying to connect to the FTP
> (Explicit).
> java.net.SocketException: Operation timed out: connect:could be due to
> invalid address.
> I am facing this error when i am running the code from the client machine
> which is in different domain...If i run the same code in the domain where ftp
> exists..it works fine without any issue...below is my code and the trace
> logPls help.
> FTPSClient client = new FTPSClient("TLS",false);
> client.addProtocolCommandListener(new PrintCommandListener(new
> PrintWriter(System.out)));
> boolean _ftp_login = false;
>
> try {
> String[] hname = ftpurl.split("//");
> client.setAuthValue("TLS");
> client.setRemoteVerificationEnabled(false);
> client.connect("ftp.kotaklifeinsurance.com",22);
>
> int reply = client.getReplyCode();
> client.execPBSZ(0);
> client.execPROT("P");
>
> if (!FTPReply.isPositiveCompletion(reply)) {
> client.disconnect();
> System.out.println("openFTPClient(): FTP server refused
> connection.");
> throw new Exception("FTP server refused connection.");
> } else {
> try {
> _ftp_login = client.login(userID, password);
> } catch (Exception e) {
> throw e;
> }
> if (_ftp_login) {
>
> client.enterLocalPassiveMode();
>
> if (client.printWorkingDirectory() == null)
> throw new Exception("Current working directory
> returned is null");
> client.changeWorkingDirectory("/XYZ/");
> fis = new FileInputStream(localfile);
> ins = (InputStream)fis;
> boolean flag = client.storeFile(filename,ins);
> System.out.println("File saved to FTP : "+flag);
> Error Trace :
> 220 Unauthorized Access Prohibited.
> AUTH TLS
> 234 AUTH command ok. Expecting TLS Negotiation.
> PBSZ 0
> 200 PBSZ command successful.
> PROT P
> 200 PROT command successful.
> USER userid
> 331 Password required for userid.
> PASS password
> 230 User logged in.
> PWD
> 257 "/" is current directory.
> CWD /XYZ/
> 250 CWD command successful.
> PWD
> 257 "/XYZ" is current directory.
> TYPE A
> 200 Type set to A.
> MODE I
> 501 'MODE I': parameter not understood.
> STRU F
> 200 STRU F ok.
> PASV
> 227 Entering Passive Mode (192,168,201,220,195,108).
> java.net.SocketException: Operation timed out: connect:could be due to
> invalid address
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:331)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:196)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:183)
> at java.net.Socket.connect(Socket.java:478)
> at java.net.Socket.connect(Socket.java:428)
> at java.net.Socket.(Socket.java:335)
> at java.net.Socket.(Socket.java:150)
> at com.ibm.jsse.bs.(Unknown Source)
> at com.ibm.jsse.JSSESocketFactory.createSocket(Unknown Source)
> at
> org.apache.commons.net.ftp.FTPSSocketFactory.createSocket(FTPSSocketFactory.java:48)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
> at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:374)
> at org.apache.commons.net.ft
[jira] Commented: (NET-363) Can't connect to a server behind firewall in passive mode
[
https://issues.apache.org/jira/browse/NET-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002888#comment-13002888
]
daniel damon commented on NET-363:
--
Here is a diff for changes that I made that work for me:
28a29
> import java.net.SocketException;
285c286
<
---
> private boolean __useRemoteAddress = false;
592c593,602
< socket = _socketFactory_.createSocket(__passiveHost,
__passivePort);
---
> //if __passiveHost fails, try the original InetAddress. Server
> may be behind firewall.
> if (__useRemoteAddress) {
> socket =
> _socketFactory_.createSocket(getRemoteAddress().getHostAddress(),
> __passivePort);
> }else try {
> socket = _socketFactory_.createSocket(__passiveHost,
> __passivePort);
> } catch (SocketException e) {
> socket =
> _socketFactory_.createSocket(getRemoteAddress().getHostAddress(),
> __passivePort);
> __useRemoteAddress=true;
> }
>
> Can't connect to a server behind firewall in passive mode
> -
>
> Key: NET-363
> URL: https://issues.apache.org/jira/browse/NET-363
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2
> Environment: Windows Client with Zos mainframe server behind a
> firewall. However I think any client/server will demonstrate the issue as
> long as the server is behind a firewall.
>Reporter: daniel damon
>Priority: Blocker
>
> When the FTP server is behind a firewall, FTPClient can connect, but it
> cannot transfer data. This is because the FTP server provides it's own
> address instead of the firewall address to make the connection. I have
> confirmed the problem by hacking a copy of FTPClient to set the __passiveHost
> to the appropriate internet address. With this hack, I can transfer data.
> Perhaps the FTP server could be configured differently to fix the issue.
> Unfortunately, I do not have access to the server configuration. I do know
> that the commercial product IpswitchFtp does deal with the issue as this
> extract from it's log shows:
>
> PASV
> 227 Entering Passive Mode (192,168,13,11,195,129)
> connecting data channel to 192.168.13.11:195,129(50049)
> Substituting connection address 159.106.121.79 for private address
> 192.168.13.11 from PASV
> data channel connected to 159.106.121.79:195,129(50049)
> LIST
> 125 List started OK
> transferred 4157 bytes in 0.078 seconds, 425.688 kbps ( 53.211 kBps),
> transfer succeeded.
> 250 List completed successfully.
> QUIT
>
> I can take a shot at a fix if you want. I'll set some timeout, and if that
> fails, I'll use the original address
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-363) Can't connect to a server behind firewall in passive mode
Can't connect to a server behind firewall in passive mode - Key: NET-363 URL: https://issues.apache.org/jira/browse/NET-363 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 2.2 Environment: Windows Client with Zos mainframe server behind a firewall. However I think any client/server will demonstrate the issue as long as the server is behind a firewall. Reporter: daniel damon Priority: Blocker When the FTP server is behind a firewall, FTPClient can connect, but it cannot transfer data. This is because the FTP server provides it's own address instead of the firewall address to make the connection. I have confirmed the problem by hacking a copy of FTPClient to set the __passiveHost to the appropriate internet address. With this hack, I can transfer data. Perhaps the FTP server could be configured differently to fix the issue. Unfortunately, I do not have access to the server configuration. I do know that the commercial product IpswitchFtp does deal with the issue as this extract from it's log shows: PASV 227 Entering Passive Mode (192,168,13,11,195,129) connecting data channel to 192.168.13.11:195,129(50049) Substituting connection address 159.106.121.79 for private address 192.168.13.11 from PASV data channel connected to 159.106.121.79:195,129(50049) LIST 125 List started OK transferred 4157 bytes in 0.078 seconds, 425.688 kbps ( 53.211 kBps), transfer succeeded. 250 List completed successfully. QUIT I can take a shot at a fix if you want. I'll set some timeout, and if that fails, I'll use the original address -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-296) java.net.SocketException: Operation timed out error while entering Passive mode
[
https://issues.apache.org/jira/browse/NET-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002854#comment-13002854
]
daniel damon commented on NET-296:
--
I am also seeing the problem. While I can get a connection, I cannot transfer
data. I can use a commercial offering to do so.
I believe the problem occurs when the FTP server is behind a firewall. When it
responds to the PASV command, it gives it's address, not the firewall address.
If the FTPClient responds to that address, of course it will fail.
Something like this probably needs to happen: The FTPClient tries to open at
the given address. If it does not work, try the original address with the
given port.
> java.net.SocketException: Operation timed out error while entering Passive
> mode
> ---
>
> Key: NET-296
> URL: https://issues.apache.org/jira/browse/NET-296
> Project: Commons Net
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows XP, JDK 1.5.0_15, commons-net-2.0-jdk14.jar
>Reporter: Hariprasad K S
>Priority: Blocker
>
> Hi,
> I am getting the following error while trying to connect to the FTP
> (Explicit).
> java.net.SocketException: Operation timed out: connect:could be due to
> invalid address.
> I am facing this error when i am running the code from the client machine
> which is in different domain...If i run the same code in the domain where ftp
> exists..it works fine without any issue...below is my code and the trace
> logPls help.
> FTPSClient client = new FTPSClient("TLS",false);
> client.addProtocolCommandListener(new PrintCommandListener(new
> PrintWriter(System.out)));
> boolean _ftp_login = false;
>
> try {
> String[] hname = ftpurl.split("//");
> client.setAuthValue("TLS");
> client.setRemoteVerificationEnabled(false);
> client.connect("ftp.kotaklifeinsurance.com",22);
>
> int reply = client.getReplyCode();
> client.execPBSZ(0);
> client.execPROT("P");
>
> if (!FTPReply.isPositiveCompletion(reply)) {
> client.disconnect();
> System.out.println("openFTPClient(): FTP server refused
> connection.");
> throw new Exception("FTP server refused connection.");
> } else {
> try {
> _ftp_login = client.login(userID, password);
> } catch (Exception e) {
> throw e;
> }
> if (_ftp_login) {
>
> client.enterLocalPassiveMode();
>
> if (client.printWorkingDirectory() == null)
> throw new Exception("Current working directory
> returned is null");
> client.changeWorkingDirectory("/XYZ/");
> fis = new FileInputStream(localfile);
> ins = (InputStream)fis;
> boolean flag = client.storeFile(filename,ins);
> System.out.println("File saved to FTP : "+flag);
> Error Trace :
> 220 Unauthorized Access Prohibited.
> AUTH TLS
> 234 AUTH command ok. Expecting TLS Negotiation.
> PBSZ 0
> 200 PBSZ command successful.
> PROT P
> 200 PROT command successful.
> USER userid
> 331 Password required for userid.
> PASS password
> 230 User logged in.
> PWD
> 257 "/" is current directory.
> CWD /XYZ/
> 250 CWD command successful.
> PWD
> 257 "/XYZ" is current directory.
> TYPE A
> 200 Type set to A.
> MODE I
> 501 'MODE I': parameter not understood.
> STRU F
> 200 STRU F ok.
> PASV
> 227 Entering Passive Mode (192,168,201,220,195,108).
> java.net.SocketException: Operation timed out: connect:could be due to
> invalid address
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:331)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:196)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:183)
> at java.net.Socket.connect(Socket.java:478)
> at java.net.Socket.connect(Socket.java:428)
> at java.net.Socket.(Socket.java:335)
> at java.net.Socket.(Socket.java:150)
> at com.ibm.jsse.bs.(Unknown Source)
> at com.ibm.jsse.JSSESocketFactory.createSocket(Unknown Source)
> at
> org.apache.commons.net.ftp.FTPSSocketFactory.createSocket(FTPSSocketFactory.java:48)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
> at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:374)
> a
[jira] Commented: (NET-258) Implement A Keepalive Mechanism
[ https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002692#comment-13002692 ] Sebb commented on NET-258: -- It's a question of using a router that times out idle connections - no need to inspect the traffic. But yes, we will probably just have to wait. Since the feature is optional, it is not critical if it causes problems for some routers/servers - though of course it would be nice to fix that. > Implement A Keepalive Mechanism > --- > > Key: NET-258 > URL: https://issues.apache.org/jira/browse/NET-258 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 2.0 >Reporter: Rory Winston > Fix For: 3.0 > > Attachments: ftp-keepalive.diff > > > For routers/firewalls that terminate idle connections, a separate heartbeat > mechanism may need to be implemented to keep the control connection active. > Some potential issues: > * Synchronization between a heartbeat write and a __getReply() on an active > control connection command; > * Should use the NOOP command as a heartbeat signal; > * Make the timeout configurable; > * Default SocketImpl::setKeepAlive() wont do here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (VFS-348) Upgrade to commons-net 2.2
[ https://issues.apache.org/jira/browse/VFS-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated VFS-348: --- Attachment: vfs-net22.patch Trivial patch to upgrade to commons-net 2.2 and remove the invokation of a deprecated method at the same time. > Upgrade to commons-net 2.2 > -- > > Key: VFS-348 > URL: https://issues.apache.org/jira/browse/VFS-348 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: Nightly Builds, 2.0 >Reporter: Stefan Bodewig >Priority: Minor > Attachments: vfs-net22.patch > > > commons-net says they recommend all users of 2.0 should upgrade to 2.2 > because of the number of fixed issues. Who knows, maybe some of the FTP > issues of VFS are addressed as well. > It would also make the commons-vfs2 build in Gump work again. > The patch is trivial and the one I'll append also fixes the usage of a > deprecated method - inside a log statement inside the example code, yay - > which is required to make Gump happy. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (VFS-348) Upgrade to commons-net 2.2
Upgrade to commons-net 2.2 -- Key: VFS-348 URL: https://issues.apache.org/jira/browse/VFS-348 Project: Commons VFS Issue Type: Improvement Affects Versions: Nightly Builds, 2.0 Reporter: Stefan Bodewig Priority: Minor commons-net says they recommend all users of 2.0 should upgrade to 2.2 because of the number of fixed issues. Who knows, maybe some of the FTP issues of VFS are addressed as well. It would also make the commons-vfs2 build in Gump work again. The patch is trivial and the one I'll append also fixes the usage of a deprecated method - inside a log statement inside the example code, yay - which is required to make Gump happy. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-258) Implement A Keepalive Mechanism
[ https://issues.apache.org/jira/browse/NET-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002575#comment-13002575 ] Bogdan Drozdowski commented on NET-258: --- Yes, you were lucky to find both types of servers that easily. I'm glad everything works. Unfortunately, I don't have a router that looks into the traffic and handles FTP connections. I don't think that such a router would disconnect the connection after a timeout (it should be the server's job to do this), but I know that routes that interfere with FTP exist. The only thing that is left to do is wait for user complaints (if there will be any). :) > Implement A Keepalive Mechanism > --- > > Key: NET-258 > URL: https://issues.apache.org/jira/browse/NET-258 > Project: Commons Net > Issue Type: Improvement > Components: FTP >Affects Versions: 2.0 >Reporter: Rory Winston > Fix For: 3.0 > > Attachments: ftp-keepalive.diff > > > For routers/firewalls that terminate idle connections, a separate heartbeat > mechanism may need to be implemented to keep the control connection active. > Some potential issues: > * Synchronization between a heartbeat write and a __getReply() on an active > control connection command; > * Should use the NOOP command as a heartbeat signal; > * Make the timeout configurable; > * Default SocketImpl::setKeepAlive() wont do here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LANG-492) Remove code handled now by the JDK
[ https://issues.apache.org/jira/browse/LANG-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002566#comment-13002566 ] Stephen Colebourne commented on LANG-492: - Revert deletion of ArrayUtils.hashCode() as it did something different to the JDK method > Remove code handled now by the JDK > -- > > Key: LANG-492 > URL: https://issues.apache.org/jira/browse/LANG-492 > Project: Commons Lang > Issue Type: Task > Components: General >Reporter: Henri Yandell > Fix For: 3.0 > > > enum, enums packages removed. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
