[jira] Commented: (IO-127) Move to a minimum of JDK 1.4
[
https://issues.apache.org/jira/browse/IO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534760
]
Joerg Schaible commented on IO-127:
---
There's no magic involved here, it's simply the runtime library. Using a JDK 6
compiler to produce JDK 1.3 code does not hide the classes and methods of the
JDK 6 runtime library and the compiler does not check the version of the byte
code it compiles against. Obviously you're getting in trouble running the
result with a runtime lib of JDK 1.3 if you have used methods only available in
later Java versions, since they're simply missing. However there are two
pitfalls with such an approach:
1/ A programmer might use newer functionality without recognizing it. Typical
trap is e.g.
new RuntimeException("Rethrow", ex);
JDK 1.3's RuntimeException has no constructors taking a causing exception.
2/ The compiler selects a different overloaded method in a newer JDK. Prominent
example is
new StringBuffer(stringBuffer);
JDK 1.3's StringBuffer has only a constructor with a String, while in JDK 1.4
it also has a constructor taking a StringBuffer. Therefore compiling with a
newer JDK it will select the new constructor, while compiling with JDK 1.3 will
convert the argument first to a String before creating the StringBuffer.
Both problems can be avoided if we use a CI to compile the JDK 1.3 compatible
classes only with JDK 1.3. That's the way we do with XStream:
http://bamboo.ci.codehaus.org/browse/XSTREAM-JDK13. In XStream we even used a
two-phased compile step for JDK 5 dependent code (annotation, enums) and JDK
1.3 compatible source code. All is delivered in one artifact. Works quite well
now for years.
> Move to a minimum of JDK 1.4
>
>
> Key: IO-127
> URL: https://issues.apache.org/jira/browse/IO-127
> Project: Commons IO
> Issue Type: Task
>Reporter: Niall Pemberton
>Priority: Minor
> Fix For: 1.4
>
> Attachments: commons-io-jdk-1_3-check.patch
>
>
> There was a discussion a while back on moving Commons IO to a minimum JDK
> version of 1.4 - see [1] below. The majority view was this was a good idea.
> Jorg Schaible suggested[2] that the compiler options be kept at JDK 1.3 so
> that, apart from new JDK 1.4 dependant features, Commons IO would still
> operate under JDK 1.3. This seems like a good idea and resolves the issue of
> whether this would require a major version change.
> There was also a view that we should move to JDK 1.5 instead - I have no
> issue with that, but would advocate that theres no point in doing so until
> there are people wanting to commit JDK 1.5 dependant features.
> This change is targeted at Commons IO 1.4 - and a Commons IO 1.3 branch has
> been created for anyone still desiring future JDK 1.3 only releases.
> [1] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL
> PROTECTED]
> [2] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL
> PROTECTED]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-129) Add TeeInputStream
[ https://issues.apache.org/jira/browse/IO-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated IO-129: - Attachment: commons-io-TeeInputStream-close.patch Not closing the output stream is designed for constructs like new TeeInputStream(..., System.out). I agree that making the close behaviour configurable is a good feature. Instead of the auto-close feature, I'd rather make the option to close the associated output stream work in the close() method of the proxy stream. See the attached patch commons-io-TeeInputStream-close.patch for a proposed implementation. One could use the AutoCloseInputStream decorator to get auto-close functionality: new AutoCloseInputStream(new TeeInputStream(..., ..., true)); > Add TeeInputStream > -- > > Key: IO-129 > URL: https://issues.apache.org/jira/browse/IO-129 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: commons-io-TeeInputStream-autoclose.patch, > commons-io-TeeInputStream-close.patch, IO-129.patch > > > There should be a TeeInputStream class that transparently writes all bytes > read from an input stream to a given output stream. Such a class could be > used to easily record and log various inputs like incoming network streams, > etc. The class would also be nicely symmetric with the existing > TeeOutputStream class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IO-129) Add TeeInputStream
[ https://issues.apache.org/jira/browse/IO-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved IO-129. Resolution: Fixed OK your patch and AutoCloseInputStream suggestion covers all bases - so I agree thats better. I've commited your patch - thanks :) > Add TeeInputStream > -- > > Key: IO-129 > URL: https://issues.apache.org/jira/browse/IO-129 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > Attachments: commons-io-TeeInputStream-autoclose.patch, > commons-io-TeeInputStream-close.patch, IO-129.patch > > > There should be a TeeInputStream class that transparently writes all bytes > read from an input stream to a given output stream. Such a class could be > used to easily record and log various inputs like incoming network streams, > etc. The class would also be nicely symmetric with the existing > TeeOutputStream class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton reopened IO-128: > NPE on FilenameUtils.equalsNormalizedOnSystem() > --- > > Key: IO-128 > URL: https://issues.apache.org/jira/browse/IO-128 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 >Reporter: Antonio Gallardo >Assignee: Niall Pemberton > Fix For: 1.4 > > > The following code in commons-io (1.3.2) throws an NPE exception: > org.apache.commons.io.FilenameUtils > .equalsNormalizedOnSystem( > "//a.html", > "//ab.html"); > And here is the exception: > java.lang.NullPointerException: The strings must not be null >at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) >at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) >at > org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) >at CodeSnippet_32.run(CodeSnippet_32.java:4) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) >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:585) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) > I think it is wrong a message "The strings must not be null", since there is > not a null string involved in the call. > Interesting is if both or 1 of the strings is null, it did not throws an > exception. > Additional comment from Niall Pemberton (on the dev mail list): > The problem is that the FilenameUtils's normalize(String) method > returns "null" if it thinks the file names are invalid - which in your > case it seems to be doing so for both file names. > So I guess theres two issues here - you're right the error is > misleading and FilenameUtils should check the names again after > calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534830 ] Niall Pemberton commented on IO-128: I'l leave the UNC issue for others to decide/fix. "For equals() the general contract is that if they are not equal then it returns false. object.equals(null) returns false for example. I don't think using the un-normalized name is the right way to go. " If both file names are invalid (but different) and therefore both result in null after normalization then it would be strange IMO to return "true" from the equals method - which was the only reason I suggested using the un-normalized name if the normalized name is null. > NPE on FilenameUtils.equalsNormalizedOnSystem() > --- > > Key: IO-128 > URL: https://issues.apache.org/jira/browse/IO-128 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 >Reporter: Antonio Gallardo >Assignee: Niall Pemberton > Fix For: 1.4 > > > The following code in commons-io (1.3.2) throws an NPE exception: > org.apache.commons.io.FilenameUtils > .equalsNormalizedOnSystem( > "//a.html", > "//ab.html"); > And here is the exception: > java.lang.NullPointerException: The strings must not be null >at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) >at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) >at > org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) >at CodeSnippet_32.run(CodeSnippet_32.java:4) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) >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:585) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) > I think it is wrong a message "The strings must not be null", since there is > not a null string involved in the call. > Interesting is if both or 1 of the strings is null, it did not throws an > exception. > Additional comment from Niall Pemberton (on the dev mail list): > The problem is that the FilenameUtils's normalize(String) method > returns "null" if it thinks the file names are invalid - which in your > case it seems to be doing so for both file names. > So I guess theres two issues here - you're right the error is > misleading and FilenameUtils should check the names again after > calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534837 ] Niall Pemberton commented on IO-128: P.S. IOCase checkEquals throws a NullPointerException if either of the Strings are null > NPE on FilenameUtils.equalsNormalizedOnSystem() > --- > > Key: IO-128 > URL: https://issues.apache.org/jira/browse/IO-128 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 >Reporter: Antonio Gallardo >Assignee: Niall Pemberton > Fix For: 1.4 > > > The following code in commons-io (1.3.2) throws an NPE exception: > org.apache.commons.io.FilenameUtils > .equalsNormalizedOnSystem( > "//a.html", > "//ab.html"); > And here is the exception: > java.lang.NullPointerException: The strings must not be null >at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) >at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) >at > org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) >at CodeSnippet_32.run(CodeSnippet_32.java:4) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) >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:585) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) > I think it is wrong a message "The strings must not be null", since there is > not a null string involved in the call. > Interesting is if both or 1 of the strings is null, it did not throws an > exception. > Additional comment from Niall Pemberton (on the dev mail list): > The problem is that the FilenameUtils's normalize(String) method > returns "null" if it thinks the file names are invalid - which in your > case it seems to be doing so for both file names. > So I guess theres two issues here - you're right the error is > misleading and FilenameUtils should check the names again after > calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-128: --- Attachment: IO-128.patch OK heres a patch replacing the exception I added. It only compares the "un-normalized" file names if they are both invalid > NPE on FilenameUtils.equalsNormalizedOnSystem() > --- > > Key: IO-128 > URL: https://issues.apache.org/jira/browse/IO-128 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 >Reporter: Antonio Gallardo >Assignee: Niall Pemberton > Fix For: 1.4 > > Attachments: IO-128.patch > > > The following code in commons-io (1.3.2) throws an NPE exception: > org.apache.commons.io.FilenameUtils > .equalsNormalizedOnSystem( > "//a.html", > "//ab.html"); > And here is the exception: > java.lang.NullPointerException: The strings must not be null >at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) >at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) >at > org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) >at CodeSnippet_32.run(CodeSnippet_32.java:4) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) >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:585) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) > I think it is wrong a message "The strings must not be null", since there is > not a null string involved in the call. > Interesting is if both or 1 of the strings is null, it did not throws an > exception. > Additional comment from Niall Pemberton (on the dev mail list): > The problem is that the FilenameUtils's normalize(String) method > returns "null" if it thinks the file names are invalid - which in your > case it seems to be doing so for both file names. > So I guess theres two issues here - you're right the error is > misleading and FilenameUtils should check the names again after > calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-128: --- Attachment: IO-128.patch > NPE on FilenameUtils.equalsNormalizedOnSystem() > --- > > Key: IO-128 > URL: https://issues.apache.org/jira/browse/IO-128 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 >Reporter: Antonio Gallardo >Assignee: Niall Pemberton > Fix For: 1.4 > > Attachments: IO-128.patch > > > The following code in commons-io (1.3.2) throws an NPE exception: > org.apache.commons.io.FilenameUtils > .equalsNormalizedOnSystem( > "//a.html", > "//ab.html"); > And here is the exception: > java.lang.NullPointerException: The strings must not be null >at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) >at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) >at > org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) >at CodeSnippet_32.run(CodeSnippet_32.java:4) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) >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:585) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) > I think it is wrong a message "The strings must not be null", since there is > not a null string involved in the call. > Interesting is if both or 1 of the strings is null, it did not throws an > exception. > Additional comment from Niall Pemberton (on the dev mail list): > The problem is that the FilenameUtils's normalize(String) method > returns "null" if it thinks the file names are invalid - which in your > case it seems to be doing so for both file names. > So I guess theres two issues here - you're right the error is > misleading and FilenameUtils should check the names again after > calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IO-128) NPE on FilenameUtils.equalsNormalizedOnSystem()
[ https://issues.apache.org/jira/browse/IO-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated IO-128: --- Attachment: (was: IO-128.patch) > NPE on FilenameUtils.equalsNormalizedOnSystem() > --- > > Key: IO-128 > URL: https://issues.apache.org/jira/browse/IO-128 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 1.2, 1.3, 1.3.1, 1.3.2 >Reporter: Antonio Gallardo >Assignee: Niall Pemberton > Fix For: 1.4 > > Attachments: IO-128.patch > > > The following code in commons-io (1.3.2) throws an NPE exception: > org.apache.commons.io.FilenameUtils > .equalsNormalizedOnSystem( > "//a.html", > "//ab.html"); > And here is the exception: > java.lang.NullPointerException: The strings must not be null >at org.apache.commons.io.IOCase.checkEquals(IOCase.java:141) >at org.apache.commons.io.FilenameUtils.equals(FilenameUtils.java:984) >at > org.apache.commons.io.FilenameUtils.equalsNormalizedOnSystem(FilenameUtils.java:956) >at CodeSnippet_32.run(CodeSnippet_32.java:4) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain1.eval(ScrapbookMain1.java:20) >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:585) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.evalLoop(ScrapbookMain.java:54) >at > org.eclipse.jdt.internal.debug.ui.snippeteditor.ScrapbookMain.main(ScrapbookMain.java:35) > I think it is wrong a message "The strings must not be null", since there is > not a null string involved in the call. > Interesting is if both or 1 of the strings is null, it did not throws an > exception. > Additional comment from Niall Pemberton (on the dev mail list): > The problem is that the FilenameUtils's normalize(String) method > returns "null" if it thinks the file names are invalid - which in your > case it seems to be doing so for both file names. > So I guess theres two issues here - you're right the error is > misleading and FilenameUtils should check the names again after > calling normalize() for nulls and throw a more appropriate message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-92) Add DeferredPeriodicOutputStream
[ https://issues.apache.org/jira/browse/IO-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534864 ] Niall Pemberton commented on IO-92: --- Sorry I don't really see the point of this - how is this different from decorating a FileOutputStream with a BufferedOutputStream? Also I don't see the point in implementing DataOutput - since you can decorate any output stream using DataOutputStream to achieve this. File myFile = ... OutputStream out = new BufferedOutputStream(new FileOutputStream(myFile)); ... DataOutput dataOut = new DataOutputStream(out); out.writeInt(...); > Add DeferredPeriodicOutputStream > > > Key: IO-92 > URL: https://issues.apache.org/jira/browse/IO-92 > Project: Commons IO > Issue Type: New Feature > Components: Streams/Writers > Environment: Windows XP SP2, jdk 1.5 >Reporter: Michele Mazzucco > Fix For: 1.4 > > Attachments: DeferredPeriodicOutputStream.java, > DeferredPeriodicOutputStream.java, DeferredPeriodicOutputStream.java, > DeferredPeriodicOutputStreamTest.java, DeferredPeriodicOutputStreamTest.java, > DeferredPeriodicOutputStreamTest.java > > > I've extended the ThresholdingOutputStream class with a new class which > behaves different from DeferredFileOutputStream: > - when the stream is closed, the content stored in memory is *always* flushed > to disk (in DeferredFileOutputStream, instead, if the treshold > is not reached data is lost) > - DeferredFileOutputStream maintains data in memory only until the treshold > value has been reached, then it immediately writes every byte > to disk. This new implementation, instead, caches treshold bytes in memory, > and every time that value is reached (that is, treshold, 2 * threshold, etc), > it flushes data to disk. In other words it acts as a cache. > - It implements the java.io.DataOutput interface, that is, it provides > utility methods to write all primitive types (e.g. short, byte, char, int, > float, long, double and String in different formats) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IO-127) Move to a minimum of JDK 1.4
[ https://issues.apache.org/jira/browse/IO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534900 ] Niall Pemberton commented on IO-127: Using CI is a good idea - not sure how we would incorporate that into our release process - so in the meantime I've added a small ant script [1] which does the following: 1) Fails if the JDK is not 1.3 2) Tries to compile the Commons IO classes, excluding the JDK 1.4 dependant ones (currently only RegexFileFilter) So we just need to run that as a test before we do a release to ensure that JDK 1.4 or later features have not crept into the rest of the code base. I also had to remove the references to the new RegexFileFilter from FileFilterUtils, otherwise several other classes wouldn't have compiled using this script. [1] http://svn.apache.org/repos/asf/commons/proper/io/trunk/build-check-jdk13.xml > Move to a minimum of JDK 1.4 > > > Key: IO-127 > URL: https://issues.apache.org/jira/browse/IO-127 > Project: Commons IO > Issue Type: Task >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.4 > > Attachments: commons-io-jdk-1_3-check.patch > > > There was a discussion a while back on moving Commons IO to a minimum JDK > version of 1.4 - see [1] below. The majority view was this was a good idea. > Jorg Schaible suggested[2] that the compiler options be kept at JDK 1.3 so > that, apart from new JDK 1.4 dependant features, Commons IO would still > operate under JDK 1.3. This seems like a good idea and resolves the issue of > whether this would require a major version change. > There was also a view that we should move to JDK 1.5 instead - I have no > issue with that, but would advocate that theres no point in doing so until > there are people wanting to commit JDK 1.5 dependant features. > This change is targeted at Commons IO 1.4 - and a Commons IO 1.3 branch has > been created for anyone still desiring future JDK 1.3 only releases. > [1] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL > PROTECTED] > [2] http://mail-archives.apache.org/mod_mbox/commons-dev/200705.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PROXY-3) RMI Test Case Failures on Linux
[ https://issues.apache.org/jira/browse/PROXY-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534939 ] Joerg Schaible commented on PROXY-3: I can run it on Linux/JDK 6 with following brute-force patch: Index: src/test/java/org/apache/commons/proxy/provider/remoting/TestRmiProvider.java === --- src/test/java/org/apache/commons/proxy/provider/remoting/TestRmiProvider.java (Revision 584833) +++ src/test/java/org/apache/commons/proxy/provider/remoting/TestRmiProvider.java (Arbeitskopie) @@ -82,6 +82,7 @@ UnicastRemoteObject.unexportObject( implObject, true ); UnicastRemoteObject.unexportObject( registry, true ); registry = null; +System.runFinalization(); } > RMI Test Case Failures on Linux > --- > > Key: PROXY-3 > URL: https://issues.apache.org/jira/browse/PROXY-3 > Project: Commons Proxy > Issue Type: Bug >Affects Versions: 1.0 > Environment: Operating System: > Linux version 2.6.20-1.2962.fc6 ([EMAIL PROTECTED]) (gcc > version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Tue Jun 19 19:27:14 EDT 2007 > Java Version: > java version "1.6.0" > Java(TM) SE Runtime Environment (build 1.6.0-b105) > Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) >Reporter: James Carman >Assignee: James Carman > Fix For: 1.0 > > > The RMI test case fails with the following message: > testGetObjectWithInvalidName(org.apache.commons.proxy.provider.TestRmiProvider) > Time elapsed: 0.005 sec <<< ERROR! > java.rmi.server.ExportException: Port already in use: 13099; nested exception > is > : > java.net.BindException: Address already in use > at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310) > at > sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218 > ) > at > sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393) > at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129) > at > sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:19 > 0) > at > java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject. > java:293) > at > java.rmi.server.UnicastRemoteObject.exportObject(UnicastRemoteObject. > java:235) > at > java.rmi.server.UnicastRemoteObject.(UnicastRemoteObject.java:1 > 33) > at > org.apache.commons.proxy.util.rmi.RmiEchoImpl.(RmiEchoImpl.java > :31) > at > org.apache.commons.proxy.provider.TestRmiProvider.setUpRegistry(TestR > miProvider.java:49) > at > org.apache.commons.proxy.provider.TestRmiProvider.testGetObjectWithIn > validName(TestRmiProvider.java:106) > Caused by: java.net.BindException: Address already in use > at java.net.PlainSocketImpl.socketBind(Native Method) > at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359) > at java.net.ServerSocket.bind(ServerSocket.java:319) > at java.net.ServerSocket.(ServerSocket.java:185) > at java.net.ServerSocket.(ServerSocket.java:97) > at > sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMI > DirectSocketFactory.java:27) > at > sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMI > MasterSocketFactory.java:333) > at > sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:64 > 9) > at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299) > ... 35 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CONFIGURATION-297) NoSuchMethodError if reloading strategy is specified in configuration XML
[
https://issues.apache.org/jira/browse/CONFIGURATION-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-297.
Resolution: Invalid
Fix Version/s: 1.5
This problem is not related to Commons Configuration.
> NoSuchMethodError if reloading strategy is specified in configuration XML
> -
>
> Key: CONFIGURATION-297
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-297
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Windows XP, WebLogic Portal Server 10.0
>Reporter: Jin Voon
> Fix For: 1.5
>
>
> I'm using the DefaultConfigurationBuilder to load the config.xml which
> contains the configuration definitions.
> DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
> builder.setFile(new File("config.xml"));
> CombinedConfiguration cc = builder.getConfiguration(true);
> It definitely finds the config.xml file, but it keeps throwing
> java.lang.NoSuchMethodError: getClass during the loading.
> java.lang.NoSuchMethodError: getClass
> at
> org.apache.commons.configuration.beanutils.BeanHelper.loadClass(BeanH
> elper.java:297)
> at
> org.apache.commons.configuration.beanutils.BeanHelper.fetchBeanClass(
> BeanHelper.java:322)
> at
> org.apache.commons.configuration.beanutils.BeanHelper.createBean(Bean
> Helper.java:244)
> at
> org.apache.commons.configuration.beanutils.BeanHelper.createBean(Bean
> Helper.java:266)
> at
> org.apache.commons.configuration.beanutils.BeanHelper.initBean(BeanHe
> lper.java:176)
> The config.xml file is:
>
>
>
>
>throwExceptionOnMissing="true" config-name="uup" config-optional="true">
>config-class="org.apache.commons.configuration.reloading.FileChangedReloadingStrategy"/>
>
>
>
> If I remove the reloadingStrategy element from the config.xml file,
> everything works properly. I can confirm I have all the required commons
> jars in my classpath. Would anyone know what the problem is? Is there
> something wrong with my configuration file or is there something more major?
> Thanks!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-358) ObjectUtils.coalesce
[ https://issues.apache.org/jira/browse/LANG-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-358: --- Fix Version/s: LangTwo 1.0 Affects Version/s: (was: LangTwo 1.0) > ObjectUtils.coalesce > > > Key: LANG-358 > URL: https://issues.apache.org/jira/browse/LANG-358 > Project: Commons Lang > Issue Type: New Feature >Reporter: Jörg Gottschling >Priority: Minor > Fix For: LangTwo 1.0 > > > I like to see the coalesce-function from SQL implemented in ObjectUtils. > Something like this: > T ObjectUtils.coalesce(T... t) > The first object, which is not null will be returned. This would replace all > the defaultValue/defaultString/... methods, with al flexibler and shorter > method. It will also reuse an existing name. > I think it's simple. Perhaps there should be overloading methods with fixed > parameter sizes. Following the jdk this seems to a little faster: > T ObjectUtils.coalesce(T t1, T t2) > T ObjectUtils.coalesce(T t1, T t2, T t3) > ... > I would provide it, including tests, if you like. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-354) Implementation of a CloneBuilder Class
[
https://issues.apache.org/jira/browse/LANG-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-354:
---
Fix Version/s: 3.0
> Implementation of a CloneBuilder Class
> --
>
> Key: LANG-354
> URL: https://issues.apache.org/jira/browse/LANG-354
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Dave Meikle
>Priority: Minor
> Fix For: 3.0
>
> Attachments: CloneBuilder.java, CloneBuilderTest.java
>
>
> As discussed on the Mailing List an implementation of a CloneBuilder class to
> simplify creating basic clone methods like the other builders in Lang.
> Example usage would be as follows:
> public Object clone() {
> return CloneBuilder.reflectionClone(this);
> }
> or
> public Object clone() {
> return new CloneBuilder(this)
> .append("field1") // note the 'field by name' usage
> .append("field2") // rather than 'field by value'
> ...
> .append("fieldn")
> .toClone();
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-357) 5 unit test failures in ClassUtilsTest on Sun Java 1.3.1
[ https://issues.apache.org/jira/browse/LANG-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535053 ] Henri Yandell commented on LANG-357: How about outside of Eclipse? It works fine for me on OS X with 1.3. > 5 unit test failures in ClassUtilsTest on Sun Java 1.3.1 > > > Key: LANG-357 > URL: https://issues.apache.org/jira/browse/LANG-357 > Project: Commons Lang > Issue Type: Bug >Affects Versions: Nightly Builds > Environment: java version "1.3.1_15" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_15-b01) > Java HotSpot(TM) Client VM (build 1.3.1_15-b01, mixed mode) >Reporter: Gary Gregory >Priority: Minor > > 5 unit test failures in ClassUtilsTest on Sun Java 1.3.1. > All is well on: >Sun Java 1.4.2_15 >Sun Java 1.5.0_12 >Sun Java 1.6.0_02 > Failure list: > ClassUtils Tests > testConstructor(org.apache.commons.lang.ClassUtilsTest) > java.lang.NoSuchMethodError > at junit.framework.Assert.assertEquals(Assert.java:146) > at junit.framework.Assert.assertEquals(Assert.java:152) > at > org.apache.commons.lang.ClassUtilsTest.testConstructor(ClassUtilsTest.java:73) > at java.lang.reflect.Method.invoke(Native Method) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > test_isInnerClass_Class(org.apache.commons.lang.ClassUtilsTest) > java.lang.NoSuchMethodError > at junit.framework.Assert.assertEquals(Assert.java:146) > at junit.framework.Assert.assertEquals(Assert.java:152) > at > org.apache.commons.lang.ClassUtilsTest.test_isInnerClass_Class(ClassUtilsTest.java:206) > at java.lang.reflect.Method.invoke(Native Method) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) > at > org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) > test_isAssignable_ClassArray_ClassArray(org.apache.commons.lang.ClassUtilsTest) > java.lang.NoSuchMethodError > at junit.framework.Assert.assertEquals(Assert.java:146) > at junit.framework.Assert.assertEquals(Assert.java:152) > at > org.apache.commons.lang.ClassUtilsTest.test_isAssignable_ClassArray_ClassArray(ClassUtilsTest.java:222) > at java.lang.reflect.Method.invoke(Native Method) > at junit.framework.TestCase.runTest(TestCase.java:164) > at junit.framework.TestCase.runBare(TestCase.java:130) > at junit.framework.TestResult$1.protect(TestResult.java:106) > at junit.framework.TestResult.runProtected(TestResult.java:124) > at junit.framework.TestResult.run(TestResult.java:109) > at junit.framework.TestCase.run(TestCase.java:120) > at junit.framework.TestSuite.runTest(TestSuite.java:230) > at junit.framework.TestSuite.run(TestSuite.java:225) >
[jira] Closed: (LANG-349) Deadlock using ReflectionToStringBuilder
[ https://issues.apache.org/jira/browse/LANG-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-349. -- Resolution: Won't Fix I'm going to mark this as a wontfix; please reopen if you think there's more to do David, but it sounds like things are good. > Deadlock using ReflectionToStringBuilder > > > Key: LANG-349 > URL: https://issues.apache.org/jira/browse/LANG-349 > Project: Commons Lang > Issue Type: Bug >Affects Versions: 2.0 > Environment: java version "1.5.0_10" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) > Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode) > >uname -a > Linux fwjsfimat04 2.4.21-32.EL #1 SMP Fri Apr 15 21:02:58 EDT 2005 x86_64 > x86_64 x86_64 GNU/Linux >Reporter: David I. >Priority: Critical > Fix For: 2.4 > > > I used the ReflectionToStringBuilder on an object to output debugging > messages to Log4j. If this object was picked up by two different threads and > the toString() method was called at the same time in two different threads, a > deadlock occurrs. > Here is a stack trace from using jstack: > Thread 1172: (state = BLOCKED) > - java.util.Vector.hashCode() @bci=0, line=938 (Interpreted frame) > - java.util.HashMap.containsKey(java.lang.Object) @bci=6, line=377 (Compiled > frame) > - org.apache.commons.lang.builder.ReflectionToStringBuilder.toString() > @bci=50, line=522 (Compiled frame) > - > org.apache.commons.lang.builder.ReflectionToStringBuilder.toString(java.lang.Object, > org.apache.commons.lang.builder.ToStringStyle, boolean, java.lang.Class) > @bci=12, line=265 (Interpreted frame) > - > org.apache.commons.lang.builder.ReflectionToStringBuilder.toString(java.lang.Object, > org.apache.commons.lang.builder.ToStringStyle) @bci=4, line=197 (Interpreted > frame) > - > org.apache.commons.lang.builder.ToStringBuilder.reflectionToString(java.lang.Object, > org.apache.commons.lang.builder.ToStringStyle) @bci=2, line=170 (Interpreted > frame) > [...] > Thread 1191: (state = BLOCKED) > - java.util.Vector.hashCode() @bci=0, line=938 (Interpreted frame) > - java.util.HashMap.containsKey(java.lang.Object) @bci=6, line=377 (Compiled > frame) > - org.apache.commons.lang.builder.ReflectionToStringBuilder.toString() > @bci=50, line=522 (Compiled frame) > [...] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (POOL-106) Usage of System.currentTimeMillis() as key for a TreeMap
Usage of System.currentTimeMillis() as key for a TreeMap Key: POOL-106 URL: https://issues.apache.org/jira/browse/POOL-106 Project: Commons Pool Issue Type: Bug Affects Versions: 1.3 Reporter: Hauke Rabe In the method 'clearOldest' of GenericKeyedObjectPool the class ObjectTimestampPair is used as keys for a TreeMap wich compares the elements by System.currentTimeMillis(). If two ObjectTimestampPair instances have the same timestamp the value in the map will be overridden and the wrong instance will be destroyed. If you use the pool with hibernate it will be result in a Statement already close Exception. As a patch i return never zero in the compareTo method of ObjectTimestampPair. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DBCP-201) Statement closing due to unprovoked rollback
[
https://issues.apache.org/jira/browse/DBCP-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535074
]
Hauke Rabe commented on DBCP-201:
-
see
https://issues.apache.org/jira/browse/POOL-106
> 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
>
> "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
> "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd";>
>
>
> name="hibernate.connection.driver_class">org.postgresql.Driver
> password
> name="hibernate.connection.url">jdbc:postgresql://localhost/myDB
> user
> name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect
> org.hibernate.transaction.JDBCTransactionFactory
> name="hibernate.current_session_context_class">thread
>
> name="hibernate.connection.provider_class">org.hibernate.connection.DBCPConnectionProvider
>
> 3
> 3
> 6
> 1
> 3
> 3
> 1000*20
> 1
> name="hibernate.connection.release_mode">after_transaction
> true
>
>
> CODE**
> private synchronized HashMap
> 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();
> HashMap allMap =
> new HashMap();
> 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();
> ArrayList idList = new ArrayList();
> while(it.hasNext()){
> idList.add((Integer)it.next());
> }
> PreparedStatement stmt2 = conn.prepareStatement(QUERY_TRANSLATIONS);
> for(int i=0;i log_.debug("Getting crosswalk for --> " + idList.get(i));
> stmt2.setInt(1,idList.get(i));
> ResultSet rs2 = stmt2.executeQuery();
> LeadDeliveryPreferences lp = allMap.get(idList.get(i));
> while(rs2.next()){
> LeadCrosswalk lc = new LeadCrosswalk();
> log_.debug("got key --> " + rs2.getString(LeadCrosswalk.DB_NAME_COL_NM));
> lc.setName(rs2.getString(LeadCrosswalk.DB_NAME_COL_NM));
> lc.setIsMethod(rs2.getBoolean(LeadCrosswalk.DB_IS_METHOD_COL_NM));
> lc.setNameTranslation(rs2.getString(LeadCrosswalk.DB_NAME_TRANSLATION_COL_NM));
> lc.setIsRequired(rs2.getBoolean(LeadCrosswalk.DB_IS_REQUIRED_COL_NM));
> lp.addCrosswalk(lc.getName(), lc);
> }
> // prepare statement object for re-use
> stmt2.clearParameters();
> allMap.remove(idList.get(i));
> allMap.put(idList.get(i), lp);
> }
> //Query for phone ranges
> PreparedStatement stmt3 = conn.prepareStatement(QUERY_PHONE_RANGES);
> for(int i=0;i stmt3.setInt(1, idList.get(i));
> rs = stmt3.executeQuery();
> LeadDeliveryPreferences lp = allMap.get(idList.get(i));
> while(rs.next()){
> LeadDeliveryClientPhoneRanges phoneRange = new
> LeadDeliveryClientPhoneRanges();
> phoneRange.setLow(rs.getInt(Le
