[jira] Commented: (CODEC-57) Metaphone.metaphone(String) returns an empty string when passed the word why.
[ https://issues.apache.org/jira/browse/CODEC-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576512#action_12576512 ] Henri Yandell commented on CODEC-57: I think that unless we hear otherwise, we should not change the CC/GG bit. People's data needs to be likely to work, regardless of the better algorithm etc. With this specific bug though, having an empty string feels bad. Both the Ruby and Python implementations do WH-W. I don't feel a huge urge to make it WH-H just to match PHP. I'm more tempted to do the WY-Y. Any thoughts? Metaphone.metaphone(String) returns an empty string when passed the word why. --- Key: CODEC-57 URL: https://issues.apache.org/jira/browse/CODEC-57 Project: Commons Codec Issue Type: Bug Affects Versions: 1.3 Environment: Commons-codec built from source using jdk 1.4.2. OS: Windows XP Java Build: 1.4.2 Reporter: Adam Wilmore Fix For: 1.4 An empty string is returned from the Metaphone.metaphone(String) method when passed the value why. Variations on the value, such as wwwhy and wwhhhy also return empty strings. This appears to be an issue since other implementations of the metaphone algorithm, namely the PHP version, returns H when passed the value why. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CODEC-62) Implement Daitch Mokotoff Soundex
Implement Daitch Mokotoff Soundex - Key: CODEC-62 URL: https://issues.apache.org/jira/browse/CODEC-62 Project: Commons Codec Issue Type: New Feature Reporter: Henri Yandell Fix For: 1.4 http://en.wikipedia.org/wiki/Daitch-Mokotoff_Soundex -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (CODEC-63) Implement Nysiis
[ https://issues.apache.org/jira/browse/CODEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576513#action_12576513 ] Henri Yandell commented on CODEC-63: Also consider the 'dropby' variant; whatever that is. Implement Nysiis Key: CODEC-63 URL: https://issues.apache.org/jira/browse/CODEC-63 Project: Commons Codec Issue Type: New Feature Reporter: Henri Yandell Fix For: 1.4 http://en.wikipedia.org/wiki/NYSIIS -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CODEC-60) Implement Caverphone
[ https://issues.apache.org/jira/browse/CODEC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CODEC-60: --- Issue Type: New Feature (was: Task) Implement Caverphone Key: CODEC-60 URL: https://issues.apache.org/jira/browse/CODEC-60 Project: Commons Codec Issue Type: New Feature Reporter: Henri Yandell Fix For: 1.4 Attachments: Caverphone1.patch http://en.wikipedia.org/wiki/Caverphone -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CODEC-59) Add methods to Base64 which work with String instead of byte[]
[ https://issues.apache.org/jira/browse/CODEC-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CODEC-59: --- Issue Type: Improvement (was: New Feature) Add methods to Base64 which work with String instead of byte[] -- Key: CODEC-59 URL: https://issues.apache.org/jira/browse/CODEC-59 Project: Commons Codec Issue Type: Improvement Reporter: Pepijn Schmitz Priority: Minor Fix For: 1.4 It would be great if the Base64 class had String encode(byte[]) and byte[] decode(String) methods. The RFC is stated in terms of characters for the encoding, so there should be no problem with unwarranted assumptions with this. Currently everyone is having to convert to and from Strings themselves. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CODEC-60) Implement Caverphone
[ https://issues.apache.org/jira/browse/CODEC-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated CODEC-60: --- Attachment: Caverphone2.patch Attaching an implementation of Caverphone 2.0; though due to the similarities between the algorithms anyone can move the code back to 1.0 with easy modification of the source. I don't think anyone would ever want to though - except to compare the two. Implement Caverphone Key: CODEC-60 URL: https://issues.apache.org/jira/browse/CODEC-60 Project: Commons Codec Issue Type: New Feature Reporter: Henri Yandell Fix For: 1.4 Attachments: Caverphone1.patch, Caverphone2.patch http://en.wikipedia.org/wiki/Caverphone -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-198) FTPTimestampParserImpl#parseTimeStamp() is not fully testable
[
https://issues.apache.org/jira/browse/NET-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated NET-198:
-
Attachment: FTPTimestampParserImpl.patch
FTPTimestampParserImpl#parseTimeStamp() is not fully testable
-
Key: NET-198
URL: https://issues.apache.org/jira/browse/NET-198
Project: Commons Net
Issue Type: Bug
Reporter: Sebb
Attachments: FTPTimestampParserImpl.patch
The FTPTimestampParserImpl#parseTimeStamp() method is not fully testable,
because it unconditionally creates Calendar items using the current time.
In order to test for leap years and DST, the test code needs to be able to
set arbitrary times.
I suggest adding a package-private method that takes an additional Calendar
parameter, as follows:
Calendar parseTimestamp(String timestampStr, Calendar now) throws
ParseException {
// etc
This would replace the original code; the public interface would delegate to
the package-private method:
public Calendar parseTimestamp(String timestampStr) throws
ParseException {
Calendar now = Calendar.getInstance();
return parseTimestamp(timestampStr, now);
}
Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-198) FTPTimestampParserImpl#parseTimeStamp() is not fully testable
FTPTimestampParserImpl#parseTimeStamp() is not fully testable
-
Key: NET-198
URL: https://issues.apache.org/jira/browse/NET-198
Project: Commons Net
Issue Type: Bug
Reporter: Sebb
The FTPTimestampParserImpl#parseTimeStamp() method is not fully testable,
because it unconditionally creates Calendar items using the current time.
In order to test for leap years and DST, the test code needs to be able to set
arbitrary times.
I suggest adding a package-private method that takes an additional Calendar
parameter, as follows:
Calendar parseTimestamp(String timestampStr, Calendar now) throws
ParseException {
// etc
This would replace the original code; the public interface would delegate to
the package-private method:
public Calendar parseTimestamp(String timestampStr) throws
ParseException {
Calendar now = Calendar.getInstance();
return parseTimestamp(timestampStr, now);
}
Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (PROXY-11) slf4j-like discovery of the Proxy implementation to use
slf4j-like discovery of the Proxy implementation to use --- Key: PROXY-11 URL: https://issues.apache.org/jira/browse/PROXY-11 Project: Commons Proxy Issue Type: Improvement Affects Versions: 1.0 Environment: wicket Reporter: Johan Compagner I set this prio to major but for wicket it is really a blocker. In the current state i just cant use commons proxy I dont want in a general framework to make a decission which implementation that i should use Something like this should be done outside the code or at least outside my code (that slf4j or commons logging also do) Look at how slf4j does it because the commons logging way is a bit flawed (classloading problems) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (NET-188) FTPClient#listFiles returns null element when file's timestamp is 02/29
[
https://issues.apache.org/jira/browse/NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576538#action_12576538
]
Sebb commented on NET-188:
--
Just found that the test works on Java 1.5 but fails with Java 1.4 (and
probably 1.3)
Presumably something has changed in the Java 1.5 run-time library.
Since net 1.5 is targetted at Java 1.3 the problem needs to be fixed.
There also clearly need to be test cases for Feb 29.
I think full testing depends on NET-198 being applied, but one can run the
following Feb 29 test at present:
{code}
public void testParseFeb29() throws Exception {
FTPTimestampParserImpl parser = new FTPTimestampParserImpl();
Calendar cal;
cal=parser.parseTimestamp(feb 29 20:04);
int dom = cal.get(Calendar.DAY_OF_MONTH);
int mon = cal.get(Calendar.MONTH);
if (dom != 29 || mon != Calendar.FEBRUARY){
mon++;
fail(failed to parse Feb 29; gave mon=+mon+ dom=+dom);
}
}
{code}
FTPClient#listFiles returns null element when file's timestamp is 02/29
-
Key: NET-188
URL: https://issues.apache.org/jira/browse/NET-188
Project: Commons Net
Issue Type: Bug
Affects Versions: 1.4
Reporter: HONMA Hirotaka
Attachments: commons-net-ftp-date-parser-feb29.patch,
DstParseTest.java, UnixParseLeapTest.patch
This issue has same cause as VALIDATOR-221.
org.apache.commons.net.ftp.parser.FTPTimestampParserImpl#parseTimestamp
throws ParseException with timestampStr = Feb 29 11:22.
FTP Server status:
{code}
[EMAIL PROTECTED] test-commonsnet]# pwd
/tmp/test-commonsnet
[EMAIL PROTECTED] test-commonsnet]# ls -l
total 0
-rw-r--r-- 1 root root 0 Dec 19 2006 aaa.txt
-rw-r--r-- 1 root root 0 Feb 29 11:22 bbb.txt
{code}
test code:
{code}
public void testCommonsNetLeapDay() throws Exception {
final FTPClient ftp = new FTPClient();
ftp.connect(host);
ftp.login(user, password);
final FTPFile[] listFiles = ftp.listFiles(/tmp/test-commonsnet);
for (int i = 0; i listFiles.length; i++) {
System.out.println([ + i + ] + listFiles[i]);
}
ftp.disconnect();
}
{code}
results bellow.
{code}
[0] -rw-r--r--1 00 0 Dec 18 2006 aaa.txt
[1] null
{code}
Second element(bbb.txt) should not be null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-416) Import MethodUtils and ConstructorUtils from BeanUtils
[ https://issues.apache.org/jira/browse/LANG-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576540#action_12576540 ] Matt Benson commented on LANG-416: -- See Hen's post http://commons.markmail.org/message/apidlhmmdqgsotdr?q=list:org%2Eapache%2Ecommons%2Edev . I had been planning to add similar code to Lang precisely because I'd never noticed these classes in BeanUtils. I simply share Hen's opinion that this type of functionality is fundamental enough to belong in Lang. Import MethodUtils and ConstructorUtils from BeanUtils -- Key: LANG-416 URL: https://issues.apache.org/jira/browse/LANG-416 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.4 Reporter: Matt Benson Fix For: 3.0 Mentioned on the mailing list... After we release 2.4 I'd like to: - import ConstructorUtils - make CU.getMatchingAccessibleConstructor() public - import MethodUtils - factor best-match calculation code out of MethodUtils into abstract superclass MemberUtils, make ConstructorUtils extend MemberUtils and use the same code (be on the lookout for ways to improve best-match calcs; my original description was based on javadoc that said the first matching method encountered was used, but this comment seems to have been outdated). - merge any other duplicate (or near-duplicate) code from CU/MethodU into MemberU and remove anything else that doesn't make sense in the context of Lang. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (NET-198) FTPTimestampParserImpl#parseTimeStamp() is not fully testable
[
https://issues.apache.org/jira/browse/NET-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rory Winston closed NET-198.
Resolution: Fixed
Fix Version/s: 2.0
1.5
FTPTimestampParserImpl#parseTimeStamp() is not fully testable
-
Key: NET-198
URL: https://issues.apache.org/jira/browse/NET-198
Project: Commons Net
Issue Type: Bug
Reporter: Sebb
Fix For: 1.5, 2.0
Attachments: FTPTimestampParserImpl.patch
The FTPTimestampParserImpl#parseTimeStamp() method is not fully testable,
because it unconditionally creates Calendar items using the current time.
In order to test for leap years and DST, the test code needs to be able to
set arbitrary times.
I suggest adding a package-private method that takes an additional Calendar
parameter, as follows:
Calendar parseTimestamp(String timestampStr, Calendar now) throws
ParseException {
// etc
This would replace the original code; the public interface would delegate to
the package-private method:
public Calendar parseTimestamp(String timestampStr) throws
ParseException {
Calendar now = Calendar.getInstance();
return parseTimestamp(timestampStr, now);
}
Patch to follow.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (NET-36) [net] PATCH] FTP and FTPClient changes
[ https://issues.apache.org/jira/browse/NET-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-36. --- Resolution: Fixed Fix Version/s: 2.0 [net] PATCH] FTP and FTPClient changes -- Key: NET-36 URL: https://issues.apache.org/jira/browse/NET-36 Project: Commons Net Issue Type: Bug Affects Versions: 1.2 Environment: Operating System: other Platform: Other Reporter: Joseph Hindsley Fix For: 2.0 Attachments: FTP.java.patch.txt, FTPClient.java.patch.txt, FTPTest.java.patch.txt, FTPTest.java.patch.txt I've included 3 patch files for changes I've made to the FTP andFTPClient classes in the commons-net package. The first patch is for the FTP class making it extend SocketClientinstead of TelnetClient. I noticed that the behavior of theTelnetClient's input stream reader thread was effectively ignoring thesocket's SOTimeout causing reads to hang forever if the server decidednot to respond to a client request at all. This should also answer oneof the goals from the TODO list: Divorce FTPClient from TelnetClient, getting rid of the TelnetClientthreads which cause problems on some platforms (e.g., MacOS). The second patch is for an FTPTest unit test. I've covered most of thebasic methods (connect(), disconnect(), sendCommand(), getReplyCode(),etc). Ignored for now are the convenience methods since they all callsendCommand() underneath. Part of the FTPTest class is a DummyFTPServerinner class which is used to communicate to the test FTP class - don'tknow if that would be useful elsewhere (maybe part of FTPClient unittests), so you might consider making it a utility class for other unittests. Finally I've attached a patch for minor changes to FTPClient: - changed __storeFile() from private to protected so that it can beused by classes that extend FTPClient - added __storeFile(String, String) method - so that the commands itaccepts are not limited to what's found in FTPCommand. Note: the__storeFile(int, String) method now calls the __storeFile(String,String) method. - added _openDataConnection_(String, String) method - so that thecommands it accepts are not limited to what's found in FTPCommand. Note:the _openDataConnection_(int, String) method now calls the_openDataConnection_(String, String) method. Hopefully you'll find the changes agreeable and will incorporate theminto the code base. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (NET-193) FTP throw NullPointerException when enountering 02-29-2008 (leap year bug)
[ https://issues.apache.org/jira/browse/NET-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-193. Resolution: Fixed Fix Version/s: 2.0 1.5 FTP throw NullPointerException when enountering 02-29-2008 (leap year bug) -- Key: NET-193 URL: https://issues.apache.org/jira/browse/NET-193 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: Ant 1.7 commons-net-1.4.1 java 1.6.0_01 Windows 2003 (build machine) Windows 2003 FTP server Reporter: j burtram Fix For: 1.5, 2.0 ant FTP task blowing up when parsing directories containing ANY items dated (created/modified) February 29 2008. There may be a workaround using defaultDateFormatConfig or recentDateFormatConfig - but I didn't find it (actually by messing with some of the ftp attributes my build finally stopped throwing NullPointerExceptions, but refused to list or get any files!! Always came back with 0 files found) Not sure the date format used by Windows FTP server - One thing I am sure of: tasks that once worked stopped working on Friday - it took all weekend and most of today to figure it out. By updating files and folders, magically ftp task begins working agains and I slowly begin regain my sanity Here's the exception: D:\builds\build.xml:23: java.lang.NullPointerException at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:115) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) at org.apache.tools.ant.Project.executeTarget(Project.java:1298) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1181) at org.apache.tools.ant.Main.runBuild(Main.java:698) at org.apache.tools.ant.Main.startAnt(Main.java:199) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) Caused by: java.lang.NullPointerException at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scandir(FTP.java:374) at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.accountForIncludedDir(FTP.java:459) at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scandir(FTP.java:383) at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.checkIncludePatterns(FTP.java:270) at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scan(FTP.java:233) at org.apache.tools.ant.taskdefs.optional.net.FTP.transferFiles(FTP.java:1570) at org.apache.tools.ant.taskdefs.optional.net.FTP.transferFiles(FTP.java:1683) at org.apache.tools.ant.taskdefs.optional.net.FTP.execute(FTP.java:2373) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) ... 11 more --- Nested Exception --- java.lang.NullPointerException at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scandir(FTP.java:374) at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.accountForIncludedDir(FTP.java:459) at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scandir(FTP.java:383) at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.checkIncludePatterns(FTP.java:270) at org.apache.tools.ant.taskdefs.optional.net.FTP$FTPDirectoryScanner.scan(FTP.java:233) at org.apache.tools.ant.taskdefs.optional.net.FTP.transferFiles(FTP.java:1570) at org.apache.tools.ant.taskdefs.optional.net.FTP.transferFiles(FTP.java:1683) at org.apache.tools.ant.taskdefs.optional.net.FTP.execute(FTP.java:2373) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
[jira] Updated: (NET-195) Ntpv3Impl attempts double-checked locking
[ https://issues.apache.org/jira/browse/NET-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston updated NET-195: - Priority: Minor (was: Major) Ntpv3Impl attempts double-checked locking - Key: NET-195 URL: https://issues.apache.org/jira/browse/NET-195 Project: Commons Net Issue Type: Bug Reporter: Sebb Priority: Minor The NtpV3Impl#getDatagramPacket() method implements double-checked locking, which is known not to work. The initial if (dp == null) condition should be removed; once this is done, the synch block could be removed and the method synchronized instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (NET-196) POP3Reply.OK and .ERROR should be final; likewise the psi fields in TelnetOption
[ https://issues.apache.org/jira/browse/NET-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston updated NET-196: - Priority: Trivial (was: Major) Issue Type: Improvement (was: Bug) POP3Reply.OK and .ERROR should be final; likewise the psi fields in TelnetOption Key: NET-196 URL: https://issues.apache.org/jira/browse/NET-196 Project: Commons Net Issue Type: Improvement Reporter: Sebb Priority: Trivial -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (NET-152) FTPClient.retrieveFileStream hangs occassionally
[ https://issues.apache.org/jira/browse/NET-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-152. Resolution: Cannot Reproduce FTPClient.retrieveFileStream hangs occassionally Key: NET-152 URL: https://issues.apache.org/jira/browse/NET-152 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: Redhat Enterprise Linux 4 Reporter: Shashi Anand B Occassionally, retrieveFileStream on FTPClient hangs. The thread dump gives the following trace: java.net.PlainSocketImpl.socketAccept (native method) java.net.PlainSocketImpl.accept (PlainSocketImpl.java:353) java.net.ServerSocket.implAccept (ServerSocket.java:448) java.net.ServerSocket.accept (ServerSocket.java:419) org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502) org.apache.commons.net.ftp.FTPClient.retrieveFileStream(FTPClient.java:1,342) This seems to occur randomly. Hence, I have not been able to get any specific information for further debugging. Is this a known issue? Is there any work-around for this issue? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (NET-162) Logout failure
[ https://issues.apache.org/jira/browse/NET-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-162. Resolution: Cannot Reproduce Logout failure -- Key: NET-162 URL: https://issues.apache.org/jira/browse/NET-162 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: Windows Reporter: Arash Joorabchi Hi all, I have a small class that just logs into a FTP serever and then Logs out I tried both of the following lines for logging out 1. ftp.logout(); 2. ftp.sendCommand(quit); and they both cause this exception: Connected to www.ideas.ie. 220 ProFTPD 1.3.0a Server (IDEAs FTP Server) [193.1.99.22] 230 User logged in. java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) 0 at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:237) at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114) at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535) at java.lang.Thread.run(Thread.java:619) Any suggestions ? Does ftp.disconnect has the same effect as logging out ? Because disconnect function works allright. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-41) [dbcp][patch] docs lie: NOT maxIdle = 0 for no limit BUT -1
[ https://issues.apache.org/jira/browse/DBCP-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-41: Affects Version/s: (was: 1.2.1) 1.2.2 maxActive documentation error applies to 1.2.2 configuration.xml. Javadoc for BasicDataSource also needs to be fixed. [dbcp][patch] docs lie: NOT maxIdle = 0 for no limit BUT -1 --- Key: DBCP-41 URL: https://issues.apache.org/jira/browse/DBCP-41 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Environment: Operating System: other Platform: Other Reporter: Anton Tagunov Fix For: 1.3 Attachments: maxIdleNegativeForNoLimit.diff, maxIdleNegativeForNoLimitFixed.diff Documnentation for BasicDataSource and in a number of other places say: setMaxIdle( 0 ) for no limit. But GenericObjectPool says that _negative_ (-1 for instance) should be used for this purpose. In our neighbour project developers tried 0 and pool appeared to be non-functional: a new connection was created each time. They said: oh, well, drop dbcp, it does not work! I consider this doc update so critical that I'm submitting a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-41) [dbcp][patch] docs lie: NOT maxIdle = 0 for no limit BUT -1
[ https://issues.apache.org/jira/browse/DBCP-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-41: Fix Version/s: (was: 1.2.2) 1.3 [dbcp][patch] docs lie: NOT maxIdle = 0 for no limit BUT -1 --- Key: DBCP-41 URL: https://issues.apache.org/jira/browse/DBCP-41 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Environment: Operating System: other Platform: Other Reporter: Anton Tagunov Fix For: 1.3 Attachments: maxIdleNegativeForNoLimit.diff, maxIdleNegativeForNoLimitFixed.diff Documnentation for BasicDataSource and in a number of other places say: setMaxIdle( 0 ) for no limit. But GenericObjectPool says that _negative_ (-1 for instance) should be used for this purpose. In our neighbour project developers tried 0 and pool appeared to be non-functional: a new connection was created each time. They said: oh, well, drop dbcp, it does not work! I consider this doc update so critical that I'm submitting a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (NET-149) when i am connecting to FTPServer it is throwing Truncated server reply:
[ https://issues.apache.org/jira/browse/NET-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rory Winston closed NET-149. Resolution: Cannot Reproduce when i am connecting to FTPServer it is throwing Truncated server reply: Key: NET-149 URL: https://issues.apache.org/jira/browse/NET-149 Project: Commons Net Issue Type: Bug Affects Versions: 1.4 Environment: windows 2003 server(IIS version 6.0) or windows xp Reporter: chandrasekhar reddy Configure a Microsoft IIS FTP Server on windows 2003 server or xp to have a multiline Banner Message: Default FTP Site Properties, Messages tab, Banner field. Fill the Banner filed with data and at the end of the data give 2 or more new lines(just press enter 2 or more times) and say Apply and OK. FTPClient fp = new FTPClient(); fp.connect(localhost); fp.login(anonymous,); Just perform above operations, the client program will throw exception at the time of login. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DBCP-41) [dbcp][patch] docs lie: NOT maxIdle = 0 for no limit BUT -1
[ https://issues.apache.org/jira/browse/DBCP-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved DBCP-41. - Resolution: Fixed [dbcp][patch] docs lie: NOT maxIdle = 0 for no limit BUT -1 --- Key: DBCP-41 URL: https://issues.apache.org/jira/browse/DBCP-41 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.2.2 Environment: Operating System: other Platform: Other Reporter: Anton Tagunov Fix For: 1.3 Attachments: maxIdleNegativeForNoLimit.diff, maxIdleNegativeForNoLimitFixed.diff Documnentation for BasicDataSource and in a number of other places say: setMaxIdle( 0 ) for no limit. But GenericObjectPool says that _negative_ (-1 for instance) should be used for this purpose. In our neighbour project developers tried 0 and pool appeared to be non-functional: a new connection was created each time. They said: oh, well, drop dbcp, it does not work! I consider this doc update so critical that I'm submitting a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DBCP-257) Inactive sessions are not handled properly
[ https://issues.apache.org/jira/browse/DBCP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz reopened DBCP-257: -- reopening to fix status on close Inactive sessions are not handled properly -- Key: DBCP-257 URL: https://issues.apache.org/jira/browse/DBCP-257 Project: Commons Dbcp Issue Type: Task Affects Versions: 1.2 Environment: JDK 1.4 Reporter: Raghu Dears, I am using commons-dbcp 1.2.1.jar and commons-pool 1.2 jar for obtaining a connection pooling. The setup works fine under normal conditions but i am facing problems lilke 1.when the network goes down during the interaction with db the system goes down gradually 2.The inactive sessions are not handled properly. 3.When exhaustion occurs the connection is not made properly. Currently i am using - GenericObjectPool(PoolableObjectFactory factory, int maxActive, byte whenExhaustedAction, long maxWait, int maxIdle) constructor for obtaining the objectpool. So how do you choose which constuctor to execute and depending upon the requirement i mentioned below can please guide in the configuration settings. Thanks for the help Raghu -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DBCP-251) Dependencies list is incomplete - does not say where all dependencies can be found
[ https://issues.apache.org/jira/browse/DBCP-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-251. Resolution: Won't Fix If and when the relevant maven plugin adds this information it will appear on the DBCP site. Dependencies list is incomplete - does not say where all dependencies can be found -- Key: DBCP-251 URL: https://issues.apache.org/jira/browse/DBCP-251 Project: Commons Dbcp Issue Type: Bug Reporter: Sebb http://commons.apache.org/dbcp/dependencies.html is incomplete, as it does not say where all the jars can be found. The links should probably point to the master source of the jar, rather than generic repositories such as ibiblio, so users can find all the associated documentation if need be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DBCP-257) Inactive sessions are not handled properly
[ https://issues.apache.org/jira/browse/DBCP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz closed DBCP-257. Resolution: Invalid Inactive sessions are not handled properly -- Key: DBCP-257 URL: https://issues.apache.org/jira/browse/DBCP-257 Project: Commons Dbcp Issue Type: Task Affects Versions: 1.2 Environment: JDK 1.4 Reporter: Raghu Dears, I am using commons-dbcp 1.2.1.jar and commons-pool 1.2 jar for obtaining a connection pooling. The setup works fine under normal conditions but i am facing problems lilke 1.when the network goes down during the interaction with db the system goes down gradually 2.The inactive sessions are not handled properly. 3.When exhaustion occurs the connection is not made properly. Currently i am using - GenericObjectPool(PoolableObjectFactory factory, int maxActive, byte whenExhaustedAction, long maxWait, int maxIdle) constructor for obtaining the objectpool. So how do you choose which constuctor to execute and depending upon the requirement i mentioned below can please guide in the configuration settings. Thanks for the help Raghu -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DBCP-240) Broken link for 'Naming' project in docs
[ https://issues.apache.org/jira/browse/DBCP-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz resolved DBCP-240. -- Resolution: Fixed Fix Version/s: 1.3 References removed in r 635113. Broken link for 'Naming' project in docs Key: DBCP-240 URL: https://issues.apache.org/jira/browse/DBCP-240 Project: Commons Dbcp Issue Type: Bug Reporter: Luis Parravicini Priority: Minor Fix For: 1.3 The page at http://commons.apache.org/dbcp/guide/jndi-howto.html talks about Naming, with a link to http://directory.apache.org/subprojects/naming/index.html which gives a 404. Moreover, I couldn't find the Naming subproject from Apache Directory, it seems it doesn't exist anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-261) How can I use custom object pool?
[ https://issues.apache.org/jira/browse/DBCP-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-261: - Fix Version/s: 1.4 This requires changes to both pool and dbcp, or for dbcp to decouple from pool, to support fully. How can I use custom object pool? - Key: DBCP-261 URL: https://issues.apache.org/jira/browse/DBCP-261 Project: Commons Dbcp Issue Type: New Feature Reporter: Navis Ryu Fix For: 1.4 need some injection point of custom implementation replacing pathetically inefficient org.apache.commons.pool.impl.GenericObjectPool. thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-262) Jocl properties files
[ https://issues.apache.org/jira/browse/DBCP-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-262: - Fix Version/s: 1.3 Jocl properties files - Key: DBCP-262 URL: https://issues.apache.org/jira/browse/DBCP-262 Project: Commons Dbcp Issue Type: Wish Reporter: Giuseppe Grilli Priority: Minor Fix For: 1.3 I wish to load jocl files not only from the classpath but from an absolute path too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DBCP-260) borrowObject from the AbandonedObjectPool hangs on a wait() method when the WHEN_EXHAUSTED_BLOCK is set
[ https://issues.apache.org/jira/browse/DBCP-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated DBCP-260: - Fix Version/s: 1.4 This should be fixed when AbandonedObjectPool is moved to pool. Leaving open until move, at which time this should become a pool issue. borrowObject from the AbandonedObjectPool hangs on a wait() method when the WHEN_EXHAUSTED_BLOCK is set --- Key: DBCP-260 URL: https://issues.apache.org/jira/browse/DBCP-260 Project: Commons Dbcp Issue Type: Improvement Affects Versions: 1.2, 1.2.1, 1.2.2 Environment: Windows XP, eclipse. JDK 1.6 Reporter: Meir Shahar Priority: Minor Fix For: 1.4 This bug is related to bugs #1, #38 #102. Thought the bugs are closed, I think there is a (edge condition) scenario that is not handled properly: Config: 10 active connections limit RemoveAbandoned set to 'on' RemoveAbandonedTimeout set to x (say 60 secs) Suppose 10 connections were borrowed and the 11 th request was issued, all within a time frame shorted then the timeout. The first 10 requests are in methods that do not properly release the connection. This means that the 11 th thread is waiting indefinitely until a notify is sent. The 'non releasing' threads the first 10 connections hence no notification is sent The 'garbage collection' is performed by the calling AbandonedObjectPool before calling the GenericObjectPool.borrowObject(...). This garbage collection will not be called again and the wait() will stay locked though some connections might be come available through timeout expiration. The quick n dirty workaround is to setMaxWait(...) but still I think a better solution will be along the lines of: 1. Waiting for removeAbandonedTimeout secs 2. Retry regular allocation -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DBCP-201) Statement closing due to unprovoked rollback
[
https://issues.apache.org/jira/browse/DBCP-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-201.
--
Resolution: Fixed
Pool 1.4 has been released. Please reopen if this issue recurs after upgrading
to pool 1.4
Statement closing due to unprovoked rollback
Key: DBCP-201
URL: https://issues.apache.org/jira/browse/DBCP-201
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.2.1
Environment: Linux, Hibernate, Java 5, DBCP
Reporter: Theresa Field
Fix For: 1.3
have seen closed statement errors sporadically occurring and I can't get it
under control. Even when the last execution of the statement is successful in
a recursive loop reusing the statement, I can still see this happen. The
stack and code is below. I am very curious how the rollback is getting
called. There are several more places in the code where this is occurring. It
is odd that it only happens sporadically and I have only identified 2 places
out of a couple of dozen that actually causes this to occur.
**CONFIG
?xml version=1.0 encoding=UTF-8?
!DOCTYPE hibernate-configuration PUBLIC
-//Hibernate/Hibernate Configuration DTD 3.0//EN
http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd;
hibernate-configuration
session-factory
property
name=hibernate.connection.driver_classorg.postgresql.Driver/property
property name=hibernate.connection.passwordpassword/property
property
name=hibernate.connection.urljdbc:postgresql://localhost/myDBlt;/property
property name=hibernate.connection.usernameuser/property
property
name=hibernate.dialectorg.hibernate.dialect.PostgreSQLDialect/property
property name=hibernate.transaction.factory_class
org.hibernate.transaction.JDBCTransactionFactory/property
property
name=hibernate.current_session_context_classthread/property
property
name=hibernate.connection.provider_classorg.hibernate.connection.DBCPConnectionProvider/property
!-- Not specified with 3rd party connection pool property
name=connection.pool_size20/property--
property name=hibernate.dbcp.maxActive3/property
property name=hibernate.dbcp.maxIdle3/property
property name=hibernate.dbcp.max Wait6/property
property name=hibernate.dbcp.whenExhaustedAction1/property
property name=hibernate.dbcp.ps.maxActive3/property
property name=hibernate.dbcp.ps.maxIdle3/property
property name=hibernate.dbcp.ps.maxWait1000*20/property
property name=hibernate.dbcp.ps.whenExhaustedAction1/property
property
name=hibernate.connection.release_modeafter_transaction/property
property name=hibernate.dbcp.poolPreparedStatementstrue/property
/session-factory
/hibernate-configuration
CODE**
private synchronized HashMapInteger, LeadDeliveryPreferences
queryForPreferences() throws SQLException{
// we open a session because this quartz group seems to have an
// issue retrieving the session on the first job execution
Session hibSession = HibernateUtil.getSessionFactory().openSession();
hibSession.beginTransaction();
Connection conn = hibSession.connection();
HashMapInteger, LeadDeliveryPreferences allMap =
new HashMapInteger, LeadDeliveryPreferences();
try{
PreparedStatement stmt = conn.prepareStatement(QUERY_ALL_PREF);
ResultSet rs = stmt.executeQuery();
//Query for lead delivery preferences
while(rs.next()){
LeadDeliveryPreferences lp = new LeadDeliveryPreferences();
lp.setCampaignID(rs.getInt(LeadDeliveryPreferences.DB_CAMPAIGN_ID));
lp.setCronSchedule(rs.getString(LeadDeliveryPreferences.DB_CRON_SCHEDULE));
lp.setEmail(rs.getString(LeadDeliveryPreferences.DB_EMAIL));
lp.setDeliveryEnabled(rs.getBoolean(LeadDeliveryPreferences.DB_DELIVERY_ENABLED));
lp.setDeliveryTransformer(rs.getString(LeadDeliveryPreferences.DB_DELIVERY_TRANSFORMER));
lp.setReportEnabled(rs.getBoolean(LeadDeliveryPreferences.DB_REPORT_ENABLED));
lp.setReportType(rs.getString(LeadDeliveryPreferences.DB_REPORT_TYPE));
lp.setSource(rs.getString(LeadDeliveryPreferences.DB_SOURCE));
allMap.put(rs.getInt(LeadDeliveryPreferences.DB_CAMPAIGN_ID), lp);
log_.debug(Picked up schedule for campaign: +
rs.getInt(LeadDeliveryPreferences.DB_CAMPAIGN_ID));
}
//prepare statement object for re-use
//stmt.clearParameters();
//Query for crosswalk values
Iterator it = allMap.keySet().iterator();
ArrayListInteger idList = new ArrayListInteger();
while(it.hasNext()){
idList.add((Integer)it.next());
}
PreparedStatement stmt2 = conn.prepareStatement(QUERY_TRANSLATIONS);
for(int i=0;iidList.size();i++){
log_.debug(Getting crosswalk for -- + idList.get(i));
stmt2.setInt(1,idList.get(i));
ResultSet rs2 =
[jira] Updated: (MATH-193) Minor javadoc and style fixes
[ https://issues.apache.org/jira/browse/MATH-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated MATH-193: -- Affects Version/s: (was: 1.2) 1.3 Minor javadoc and style fixes - Key: MATH-193 URL: https://issues.apache.org/jira/browse/MATH-193 Project: Commons Math Issue Type: Improvement Affects Versions: 1.3 Reporter: Michael Heuer Assignee: Brent Worden Priority: Minor Fix For: 2.0 Attachments: EmpiricalDistribution-patch.txt, EmpiricalDistributionTest-patch.txt, linear-package-javadoc-patch.txt, math.patch, ode-package-patch.txt Per discussion on the commons-dev mailing list in this thread http://tinyurl.com/326pym attached are minor javadoc and style fixes not addressed by Luc as described here http://tinyurl.com/3bp866 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-417) ClassUtils: method for turning FQN into resource path
ClassUtils: method for turning FQN into resource path
-
Key: LANG-417
URL: https://issues.apache.org/jira/browse/LANG-417
Project: Commons Lang
Issue Type: New Feature
Reporter: Paul Benedict
Fix For: 2.4
I commonly need a FQ path to a resource within the same location as a class
file. I recommend the addition of this method:
public String getPackageResourcePath(Class clazz, String resourceName)
StringBuffer buf = new StringBuffer();
buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
buf.append(/);
buf.append(resourceName);
return buf.toString();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-417) ClassUtils: method for turning FQN into resource path
[
https://issues.apache.org/jira/browse/LANG-417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576704#action_12576704
]
Paul Benedict commented on LANG-417:
This method may be better named as getClasspathResourcePath
ClassUtils: method for turning FQN into resource path
-
Key: LANG-417
URL: https://issues.apache.org/jira/browse/LANG-417
Project: Commons Lang
Issue Type: New Feature
Reporter: Paul Benedict
Fix For: 2.4
I commonly need a FQ path to a resource within the same location as a class
file. I recommend the addition of this method:
public String getPackageResourcePath(Class clazz, String resourceName)
StringBuffer buf = new StringBuffer();
buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
buf.append(/);
buf.append(resourceName);
return buf.toString();
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DBCP-252) Bugs found by Findbugs
[
https://issues.apache.org/jira/browse/DBCP-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz resolved DBCP-252.
--
Resolution: Fixed
Fixed all identified issues other than the PoolingDriver complaints which would
require backward-incompatible changes.
Bugs found by Findbugs
--
Key: DBCP-252
URL: https://issues.apache.org/jira/browse/DBCP-252
Project: Commons Dbcp
Issue Type: Bug
Reporter: Sebb
Fix For: 1.3
ManagedConnection.java has (line 155)
protected class CompletionListener implements TransactionContextListener {
public void afterCompletion(TransactionContext transactionContext,
boolean commited) {
if (transactionContext == transactionContext) {
transactionComplete();
}
}
}
The transactionContext parameter is hiding the field transactionContext.
The parameter should be renamed, as at present the comparison will always
succeed.
PoolingDriver:
===
the following fields should be final:
_pools
MAJOR_VERSION
MINOR_VERSION
URL_PREFIX
URL_PREFIX_LEN
In fact the last four should probably be private as well
toString() should not return null
CPDSConnectionFactory
===
setPool() is synch; getPool() is not. Either make both sync or make _pool
volatile.
setRollbackAfterValidation is synch, however the field it sets -
_rollbackAfterValidation - is not read using synch.
Either synch the read operation - or better here - drop the synch, and make
the field volatile
Same applies to setValidationQuery() and _validationQuery
KeyedCPDSConnectionFactory
setRollbackAfterValidation is synch, however the field it sets -
_rollbackAfterValidation - is not read using synch.
Either synch the read operation - or better here - drop the synch, and make
the field volatile
Same applies to setValidationQuery() and _validationQuery
PoolableConnectionFactory
==
setPool() is synch; getPool() is not. Either make both sync or make _pool
volatile.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
