[jira] [Created] (LANG-771) DateUtils.ceiling does not behave correctly for dates on the boundaries
DateUtils.ceiling does not behave correctly for dates on the boundaries
---
Key: LANG-771
URL: https://issues.apache.org/jira/browse/LANG-771
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.0.1
Environment: Windows XP Professional
Java 1.6
Reporter: Ryan Holmes
Priority: Minor
DateUtils.ceiling does not behave as expected for dates exactly on the
boundaries specified.
To be consistent with the name "ceiling", it follows that if a date is already
at its "ceiling", it should not be pushed any higher. Yet the current
implementation (and, it would appear, all implementations since its creation)
of DateUtils.ceiling push a value exactly on its ceiling to the next value.
Observe what happens if the following tests are added to
DateUtilsTest.testCeil():
double double4 = 15.0;
assertEquals("ceiling double-4 failed",
double4,
Math.ceil(double4));
Date date4 = dateTimeParser.parse("March 30, 2003 01:10:00.000");
assertEquals("ceiling minute-4 failed",
date4,
DateUtils.ceiling(date4, Calendar.MINUTE));
The first assert passes, as Math.ceil behaves as it should (i.e.
Mail.ceil(15.0) = 15.0).
However, the second assert fails with:
ceiling minute-4 failed expected: but
was:
as the routine incorrectly (I believe) pushes the value to the next minute.
Either the method is incorrectly named ([as previously
suggested|https://issues.apache.org/jira/browse/LANG-434?focusedCommentId=12855836#comment-12855836])
or it should probably be corrected to be consistent with expected behaviour
(using Math.ceil as a benchmark).
If changing the behaviour of DateUtils.ceiling is perceived to have too many
flow-on effects (e.g. backwards compatibility issues) then perhaps it should be
renamed to DateUtils.ceil to make it consistent with the Math class method name
and to make the change in behaviour obvious (and perhaps also have a
DateUtils.floor as a synonym for DateUtils.truncate).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-770) StringUtils.join(Object[]) performance issue if .toString() is not trivial
StringUtils.join(Object[]) performance issue if .toString() is not trivial
--
Key: LANG-770
URL: https://issues.apache.org/jira/browse/LANG-770
Project: Commons Lang
Issue Type: Bug
Reporter: Joe Barnett
I have some code that builds syntax trees, and then uses a combination of
TreeNode.toString() and StringUtils.join() to recursively convert that syntax
tree to a String representation.
example .toString() of a SumNode class, where children is a TreeNode[]:
public String toString() {
return StringUtils.join(children, "+");
}
The problem is, StringUtils.join(Object[], String, int, int) is trying to be
too smart about preallocating the StringBuffer size it uses internally, as it
does:
bufSize *= ((array[startIndex] == null ? 16 :
array[startIndex].toString().length())
+ separator.length());
followed by implicitly calling .toString() on each object in the array:
buf.append(array[i]);
For deep syntax trees, this results in incredibly bad performance, as when
traversing the syntax tree, every time we go to the first node, we re-expand
the entire tree below that node (which does the same thing with the first node
below that, etc).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-190) Add API BaseObjectPool.isOpen()
[ https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-190: - Issue Type: Bug (was: New Feature) > Add API BaseObjectPool.isOpen() > --- > > Key: POOL-190 > URL: https://issues.apache.org/jira/browse/POOL-190 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.0 > > Attachments: isOpen.diff > > > Add API BaseObjectPool.isOpen() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-190) Add API BaseObjectPool.isOpen()
[ https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz updated POOL-190: - Issue Type: New Feature (was: Bug) > Add API BaseObjectPool.isOpen() > --- > > Key: POOL-190 > URL: https://issues.apache.org/jira/browse/POOL-190 > Project: Commons Pool > Issue Type: New Feature >Affects Versions: 1.5.6 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.0 > > Attachments: isOpen.diff > > > Add API BaseObjectPool.isOpen() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-288) Supply a ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/IO-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150124#comment-13150124
]
Sebb commented on IO-288:
-
Good to know that it's easy to unambiguously detect CR and LF.
There seems to be a lot of spurious files in the zip archive.
I'm not sure that the getNewLineMatchByteCount() is as efficient as
BufferedReader.readLine() - it seems to process characters multiple times. It
could probably be improved by just checking current and previous chars. Also, I
don't think it's necessary to encode \n or \r - just use the appropriate
characters.
There are no tests for multi-block files where there may be lines spanning
blocks.
Indeed the CRLF pair may span blocks; I'm not convinced that the code handles
that correctly.
In order for getNewLineMatchByteCount() to detect all CRLF pairs, it generally
needs at least 2 characters to be present; this does not seem to be guaranteed.
Note: could use a smaller block size to make the test files smaller; probably
sensible to compare the results with a forward line reader. It would then be
simple to have a directory of various different test files - read the file
forward and store the lines; ensure that the reverse reader matches the
reversed lines.
The field totalBlockCount needs to be a long, not an int.
Might simplify the code to use empty arrays rather than null.
> Supply a ReversedLinesFileReader
> -
>
> Key: IO-288
> URL: https://issues.apache.org/jira/browse/IO-288
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Georg Henzler
> Fix For: 2.2
>
> Attachments: ReversedLinesFileReader0.2.zip
>
>
> I needed to analyse a log file today and I was looking for a
> ReversedLinesFileReader: A class that behaves exactly like BufferedReader
> except that it goes from bottom to top when readLine() is called. I didn't
> find it in IOUtils and the internet didn't help a lot either, e.g.
> http://www.java2s.com/Tutorial/Java/0180__File/ReversingaFile.htm is a fairly
> inefficient - the log files I'm analysing are huge and it is not a good idea
> to load the whole content in the memory.
> So I ended up writing an implementation myself using little memory and the
> class RandomAccessFile - see attached file. It's used as follows:
> int blockSize = 4096; // only that much memory is needed, no matter how big
> the file is
> ReversedLinesFileReader reversedLinesFileReader = new ReversedLinesFileReader
> (myFile, blockSize, "UTF-8"); // encoding is supported
> String line = null;
> while((line=reversedLinesFileReader.readLine())!=null) {
> ... // use the line
> if(enoughLinesSeen) {
> break;
> }
> }
> reversedLinesFileReader.close();
> I believe this could be useful for other people as well!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-288) Supply a ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/IO-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Henzler updated IO-288:
-
Attachment: ReversedLinesFileReader0.2.zip
I didn't really like the "inefficient" idea of using the BufferedReader to get
around the encoding issue... so I read up about encodings in general and I
think the solution as provided works for all one byte encodings, UTF-8,
UTF-16BE/UTF-16LE and Shift-JIS. For other encodings at the moment an exception
is thrown to be on the safe side (but this can be easily extended).
Also, now \r alone is treated as newline as well.
PS: Added Apache headers and removed author tag.
> Supply a ReversedLinesFileReader
> -
>
> Key: IO-288
> URL: https://issues.apache.org/jira/browse/IO-288
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Georg Henzler
> Fix For: 2.2
>
> Attachments: ReversedLinesFileReader0.2.zip
>
>
> I needed to analyse a log file today and I was looking for a
> ReversedLinesFileReader: A class that behaves exactly like BufferedReader
> except that it goes from bottom to top when readLine() is called. I didn't
> find it in IOUtils and the internet didn't help a lot either, e.g.
> http://www.java2s.com/Tutorial/Java/0180__File/ReversingaFile.htm is a fairly
> inefficient - the log files I'm analysing are huge and it is not a good idea
> to load the whole content in the memory.
> So I ended up writing an implementation myself using little memory and the
> class RandomAccessFile - see attached file. It's used as follows:
> int blockSize = 4096; // only that much memory is needed, no matter how big
> the file is
> ReversedLinesFileReader reversedLinesFileReader = new ReversedLinesFileReader
> (myFile, blockSize, "UTF-8"); // encoding is supported
> String line = null;
> while((line=reversedLinesFileReader.readLine())!=null) {
> ... // use the line
> if(enoughLinesSeen) {
> break;
> }
> }
> reversedLinesFileReader.close();
> I believe this could be useful for other people as well!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-288) Supply a ReversedLinesFileReader
[
https://issues.apache.org/jira/browse/IO-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Georg Henzler updated IO-288:
-
Attachment: (was: ReversedLinesFileReader.zip)
> Supply a ReversedLinesFileReader
> -
>
> Key: IO-288
> URL: https://issues.apache.org/jira/browse/IO-288
> Project: Commons IO
> Issue Type: New Feature
> Components: Utilities
>Reporter: Georg Henzler
> Fix For: 2.2
>
>
> I needed to analyse a log file today and I was looking for a
> ReversedLinesFileReader: A class that behaves exactly like BufferedReader
> except that it goes from bottom to top when readLine() is called. I didn't
> find it in IOUtils and the internet didn't help a lot either, e.g.
> http://www.java2s.com/Tutorial/Java/0180__File/ReversingaFile.htm is a fairly
> inefficient - the log files I'm analysing are huge and it is not a good idea
> to load the whole content in the memory.
> So I ended up writing an implementation myself using little memory and the
> class RandomAccessFile - see attached file. It's used as follows:
> int blockSize = 4096; // only that much memory is needed, no matter how big
> the file is
> ReversedLinesFileReader reversedLinesFileReader = new ReversedLinesFileReader
> (myFile, blockSize, "UTF-8"); // encoding is supported
> String line = null;
> while((line=reversedLinesFileReader.readLine())!=null) {
> ... // use the line
> if(enoughLinesSeen) {
> break;
> }
> }
> reversedLinesFileReader.close();
> I believe this could be useful for other people as well!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-217) Optional partial matching for long options
[ https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149939#comment-13149939 ] Emmanuel Bourg commented on CLI-217: Thank you for the patch Hartmut. If I understand well you suggest to give to the exact matches the priority over the partial matches, right? > Optional partial matching for long options > -- > > Key: CLI-217 > URL: https://issues.apache.org/jira/browse/CLI-217 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.3 >Reporter: Emmanuel Bourg > Fix For: 1.3 > > Attachments: optPartialMatch.patch > > > DefaultParser support partial long options (i.e --ver matches --version if > there is no ambiguity), but for some cases it might be necessary to disable > this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLI-217) Optional partial matching for long options
[ https://issues.apache.org/jira/browse/CLI-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hartmut Lang updated CLI-217: - Attachment: optPartialMatch.patch Added a patch that helps with partial matching without turning this feature off. > Optional partial matching for long options > -- > > Key: CLI-217 > URL: https://issues.apache.org/jira/browse/CLI-217 > Project: Commons CLI > Issue Type: Improvement > Components: Parser >Affects Versions: 1.3 >Reporter: Emmanuel Bourg > Fix For: 1.3 > > Attachments: optPartialMatch.patch > > > DefaultParser support partial long options (i.e --ver matches --version if > there is no ambiguity), but for some cases it might be necessary to disable > this feature. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-309) ThreadLocal memory leak in DefaultFileContent
[ https://issues.apache.org/jira/browse/VFS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149797#comment-13149797 ] jontro commented on VFS-309: This is still an issue. Why even store it in a ThreadLocal at all, it could be implemented with a custom class for storing it like described in this article: http://blog.maxant.co.uk/pebble/2008/09/23/10078.html It also would be nice to be able to clear this per thread after a request has been made in a request filter. > ThreadLocal memory leak in DefaultFileContent > - > > Key: VFS-309 > URL: https://issues.apache.org/jira/browse/VFS-309 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 > Environment: Tomcat servlet container >Reporter: jontro > > When using commons vfs in a servlet container the ThreadLocal values stored > will not be released once the request finishes. > There needs to be a method to clear these values otherwise the data will leak > into the next request. > This was detected with tomcat 6.0.26. Upon undeploying an app that uses > commons vfs tomcat detects the leaks with a huge amount of the following > messages: > A web application created a ThreadLocal with key of type > [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@52fb241d]) and a value > of type [org.apache.commons.vfs.provider.FileContentThreadData] (value > [org.apache.commons.vfs.provider.FileContentThreadData@6600167a]) but failed > to remove it when the web application was stopped. To prevent a memory leak, > the ThreadLocal has been forcibly removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-769) Please restore NotImplementedException and UnhandledException
[ https://issues.apache.org/jira/browse/LANG-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149772#comment-13149772 ] david cogen commented on LANG-769: -- Forgot to add: At the very least, these should have been deprecated rather than just removing them without warning. But as I said before, these are generally useful and I'd love to have them back. > Please restore NotImplementedException and UnhandledException > - > > Key: LANG-769 > URL: https://issues.apache.org/jira/browse/LANG-769 > Project: Commons Lang > Issue Type: Improvement >Reporter: david cogen >Priority: Minor > > Why were these removed? I found these very useful and used them often. As the > version 2.6 api javadoc states, "This exception supplements the standard > exception classes by providing a more semantically rich description of the > problem." > Just want you to realize that these have found direct use outside the > library; not just internal use within commons-lang. > I will define these missing classes myself, or maybe include both > commons-lang and commons-lang3 (but I really don't to do that). It would be > very nice to have these back. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-769) Please restore NotImplementedException and UnhandledException
Please restore NotImplementedException and UnhandledException - Key: LANG-769 URL: https://issues.apache.org/jira/browse/LANG-769 Project: Commons Lang Issue Type: Improvement Reporter: david cogen Priority: Minor Why were these removed? I found these very useful and used them often. As the version 2.6 api javadoc states, "This exception supplements the standard exception classes by providing a more semantically rich description of the problem." Just want you to realize that these have found direct use outside the library; not just internal use within commons-lang. I will define these missing classes myself, or maybe include both commons-lang and commons-lang3 (but I really don't to do that). It would be very nice to have these back. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-189) close() does not release threads blocked on borrowObject()
[ https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149769#comment-13149769 ] Phil Steitz commented on POOL-189: -- Thanks, Bill! You used the right branch and my initial reaction is this looks good. You are right that this also affects GKOP and a similar fix should work there. I will look more carefully at this tonight. Additional review / comments welcome. Thanks for the patch! > close() does not release threads blocked on borrowObject() > -- > > Key: POOL-189 > URL: https://issues.apache.org/jira/browse/POOL-189 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: java 1.6.0_24 >Reporter: Adrian Nistor > Fix For: 1.5.7 > > Attachments: BUG-189v1.diff, Test.java > > > Hi, > When I call close() and borrowObject() concurrently with no objects in > the pool, close() will finish but borrowObject() is blocked forever. > The documentation of close() mentions that borrowObject() should fail > with IllegalStateException, so I would expect the waiting threads to > throw IllegalStateException. > I will attach a test that exposes this problem. For this test, the > expected output is: > 0 > 1 > 2 > ... > 4999 > DONE > But when the bug manifests (almost always for this test), the output > is: > 0 > 1 > 2 > The test does not finish, it just gets stuck after printing several > values. > Is this a bug or am I reading the documentation wrongly? Is there > a patch for this? > Thanks! > Adrian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-77) "drop view" does not work from QueryRunner.update with SQLServer JDBC drivers. Same SQL works with a PreparedStatement just fine.
[ https://issues.apache.org/jira/browse/DBUTILS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149730#comment-13149730 ] William R. Speirs commented on DBUTILS-77: -- Agreed, the documentation should be updated to better explain what the "workaround" is actually doing, and that other JDBC Drivers might want to use it as well. I wouldn't rush to add that line to AbstractQueryRunner however. If you have a bad SQL statement, you'll be turning off the use of getParameterMetaData() when it might actually be useful with later requests. I'd propose only an update to documentation for this one... > "drop view" does not work from QueryRunner.update with SQLServer JDBC > drivers. Same SQL works with a PreparedStatement just fine. > -- > > Key: DBUTILS-77 > URL: https://issues.apache.org/jira/browse/DBUTILS-77 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.3 > Environment: Java environment: Java 6 on Redhat Linux > Database enviroment: SQLServer 2008 >Reporter: Michael Akerman > Fix For: 1.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-77) "drop view" does not work from QueryRunner.update with SQLServer JDBC drivers. Same SQL works with a PreparedStatement just fine.
[
https://issues.apache.org/jira/browse/DBUTILS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149726#comment-13149726
]
Michael Akerman commented on DBUTILS-77:
final QueryRunner qr = new QueryRunner(true);
Solves the problem. However this doesn't match the documentation of what that
feature is meant for.
Also, I think we might need:
catch (SQLException e) {
pmdKnownBroken = true;
}
In AbstractQueryRunner.java somewhere around line 172.
> "drop view" does not work from QueryRunner.update with SQLServer JDBC
> drivers. Same SQL works with a PreparedStatement just fine.
> --
>
> Key: DBUTILS-77
> URL: https://issues.apache.org/jira/browse/DBUTILS-77
> Project: Commons DbUtils
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: Java environment: Java 6 on Redhat Linux
> Database enviroment: SQLServer 2008
>Reporter: Michael Akerman
> Fix For: 1.5
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-77) "drop view" does not work from QueryRunner.update with SQLServer JDBC drivers. Same SQL works with a PreparedStatement just fine.
[ https://issues.apache.org/jira/browse/DBUTILS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149718#comment-13149718 ] William R. Speirs commented on DBUTILS-77: -- Michael, can you try it again but construct QueryRunner as follows: QueryRunner(true); The line which is causing the exception is an attempt to get meta data: stmt.getParameterMetaData(); using the QueryRunner(true) constructor will prevent this code from being run. Thanks... > "drop view" does not work from QueryRunner.update with SQLServer JDBC > drivers. Same SQL works with a PreparedStatement just fine. > -- > > Key: DBUTILS-77 > URL: https://issues.apache.org/jira/browse/DBUTILS-77 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.3 > Environment: Java environment: Java 6 on Redhat Linux > Database enviroment: SQLServer 2008 >Reporter: Michael Akerman > Fix For: 1.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-77) "drop view" does not work from QueryRunner.update with SQLServer JDBC drivers. Same SQL works with a PreparedStatement just fine.
[ https://issues.apache.org/jira/browse/DBUTILS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149705#comment-13149705 ] Michael Akerman commented on DBUTILS-77: Here is the inner SQLException: com.microsoft.sqlserver.jdbc.SQLServerException: com.microsoft.sqlserver.jdbc.SQLServerException: Unable to identify the table drop view sqlapps.rso_current_person for the metadata. at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDriverError(SQLServerException.java:171) at com.microsoft.sqlserver.jdbc.SQLServerParameterMetaData.(SQLServerParameterMetaData.java:426) at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.getParameterMetaData(SQLServerPreparedStatement.java:1510) at org.apache.commons.dbutils.AbstractQueryRunner.fillStatement(AbstractQueryRunner.java:172) at org.apache.commons.dbutils.QueryRunner.update(QueryRunner.java:485) at org.apache.commons.dbutils.QueryRunner.update(QueryRunner.java:402) at edu.uark.util.ConnectionUtils.execute(ConnectionUtils.java:66) at edu.uark.util.queryrunner.Main.main(Main.java:64) > "drop view" does not work from QueryRunner.update with SQLServer JDBC > drivers. Same SQL works with a PreparedStatement just fine. > -- > > Key: DBUTILS-77 > URL: https://issues.apache.org/jira/browse/DBUTILS-77 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.3 > Environment: Java environment: Java 6 on Redhat Linux > Database enviroment: SQLServer 2008 >Reporter: Michael Akerman > Fix For: 1.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-77) "drop view" does not work from QueryRunner.update with SQLServer JDBC drivers. Same SQL works with a PreparedStatement just fine.
[ https://issues.apache.org/jira/browse/DBUTILS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149698#comment-13149698 ] Michael Akerman commented on DBUTILS-77: The first stack trace was from the 1.2 version. Here's the stack trace from 1.4. Exception in thread "main" java.sql.SQLException: com.microsoft.sqlserver.jdbc.SQLServerException: Unable to identify the table drop view sqlapps.rso_current_person for the metadata. Query: drop view sqlapps.rso_current_person Parameters: [] at org.apache.commons.dbutils.AbstractQueryRunner.rethrow(AbstractQueryRunner.java:320) at org.apache.commons.dbutils.QueryRunner.update(QueryRunner.java:489) at org.apache.commons.dbutils.QueryRunner.update(QueryRunner.java:402) at edu.uark.util.ConnectionUtils.execute(ConnectionUtils.java:64) at edu.uark.util.queryrunner.Main.main(Main.java:64) > "drop view" does not work from QueryRunner.update with SQLServer JDBC > drivers. Same SQL works with a PreparedStatement just fine. > -- > > Key: DBUTILS-77 > URL: https://issues.apache.org/jira/browse/DBUTILS-77 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.3 > Environment: Java environment: Java 6 on Redhat Linux > Database enviroment: SQLServer 2008 >Reporter: Michael Akerman > Fix For: 1.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-77) "drop view" does not work from QueryRunner.update with SQLServer JDBC drivers. Same SQL works with a PreparedStatement just fine.
[
https://issues.apache.org/jira/browse/DBUTILS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149692#comment-13149692
]
Michael Akerman commented on DBUTILS-77:
Here's the code that fails to run the SQL for me:
final QueryRunner qr = new QueryRunner();
final int rows = qr.update( con, sql, args );
return rows;
Here's code that works:
final PreparedStatement psm = con.prepareStatement( sql
);
for ( int i=1; i <= args.length; i++ )
{
psm.setString( i, args[i].toString() );
}
int rows = psm.executeUpdate();
psm.close();
return rows;
> "drop view" does not work from QueryRunner.update with SQLServer JDBC
> drivers. Same SQL works with a PreparedStatement just fine.
> --
>
> Key: DBUTILS-77
> URL: https://issues.apache.org/jira/browse/DBUTILS-77
> Project: Commons DbUtils
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: Java environment: Java 6 on Redhat Linux
> Database enviroment: SQLServer 2008
>Reporter: Michael Akerman
> Fix For: 1.5
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-77) "drop view" does not work from QueryRunner.update with SQLServer JDBC drivers. Same SQL works with a PreparedStatement just fine.
[ https://issues.apache.org/jira/browse/DBUTILS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149690#comment-13149690 ] Michael Akerman commented on DBUTILS-77: Yes, sorry there was an exception: Exception in thread "main" java.sql.SQLException: com.microsoft.sqlserver.jdbc.SQLServerException: Unable to identify the table drop view sqlapps.rso_current_person for the metadata. Query: drop view sqlapps.rso_current_person Parameters: [] at org.apache.commons.dbutils.QueryRunner.rethrow(QueryRunner.java:540) at org.apache.commons.dbutils.QueryRunner.update(QueryRunner.java:597) > "drop view" does not work from QueryRunner.update with SQLServer JDBC > drivers. Same SQL works with a PreparedStatement just fine. > -- > > Key: DBUTILS-77 > URL: https://issues.apache.org/jira/browse/DBUTILS-77 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.3 > Environment: Java environment: Java 6 on Redhat Linux > Database enviroment: SQLServer 2008 >Reporter: Michael Akerman > Fix For: 1.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-189) close() does not release threads blocked on borrowObject()
[ https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149680#comment-13149680 ] William R. Speirs commented on POOL-189: If the above patch is correct/accepted, then the same logic can easily be applied to GenericKeyedObjectPool as well. > close() does not release threads blocked on borrowObject() > -- > > Key: POOL-189 > URL: https://issues.apache.org/jira/browse/POOL-189 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: java 1.6.0_24 >Reporter: Adrian Nistor > Fix For: 1.5.7 > > Attachments: BUG-189v1.diff, Test.java > > > Hi, > When I call close() and borrowObject() concurrently with no objects in > the pool, close() will finish but borrowObject() is blocked forever. > The documentation of close() mentions that borrowObject() should fail > with IllegalStateException, so I would expect the waiting threads to > throw IllegalStateException. > I will attach a test that exposes this problem. For this test, the > expected output is: > 0 > 1 > 2 > ... > 4999 > DONE > But when the bug manifests (almost always for this test), the output > is: > 0 > 1 > 2 > The test does not finish, it just gets stuck after printing several > values. > Is this a bug or am I reading the documentation wrongly? Is there > a patch for this? > Thanks! > Adrian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-598) DateUtils.isSameDay needs to factor in TimeZone
[ https://issues.apache.org/jira/browse/LANG-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Ricard updated LANG-598: Attachment: LANG-598.patch Here is a patch with some tests. Can someone check my javadoc and correct it if needed please? > DateUtils.isSameDay needs to factor in TimeZone > --- > > Key: LANG-598 > URL: https://issues.apache.org/jira/browse/LANG-598 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* >Affects Versions: 2.5 >Reporter: Dan Checkoway > Fix For: 3.x > > Attachments: LANG-598.patch > > > DateUtils.isSameDay works great as long as you only care about the default > system TimeZone. If you're trying to see if two Dates are the same day in > *another* TimeZone, then you're hosed. > For example, let's say the two dates being compared are: > January 1, 2010 at 8:30pm PST > January 1, 2010 at 9:30pm PST > If your system TimeZone is PST, then sure, those two dates are on the "same > day." But they are NOT the same day in EST, for example. > The fix would be simple. Add an isSameDay(Date, Date, TimeZone) method, and > simply call setTimezone on each of the Calendar objects constructed. > The isSameDay(Calendar, Calendar) method can probably be left alone, since > the caller conceivably has called setTimeZone on the Calendar objects prior > to calling isSameDay. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DBUTILS-77) "drop view" does not work from QueryRunner.update with SQLServer JDBC drivers. Same SQL works with a PreparedStatement just fine.
[ https://issues.apache.org/jira/browse/DBUTILS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149673#comment-13149673 ] Michael Akerman commented on DBUTILS-77: Yes, I'll recreate it and see what I can report. I don't recall exceptions, I think it was an error code. > "drop view" does not work from QueryRunner.update with SQLServer JDBC > drivers. Same SQL works with a PreparedStatement just fine. > -- > > Key: DBUTILS-77 > URL: https://issues.apache.org/jira/browse/DBUTILS-77 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.3 > Environment: Java environment: Java 6 on Redhat Linux > Database enviroment: SQLServer 2008 >Reporter: Michael Akerman > Fix For: 1.5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (POOL-189) close() does not release threads blocked on borrowObject()
[ https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs updated POOL-189: --- Attachment: BUG-189v1.diff > close() does not release threads blocked on borrowObject() > -- > > Key: POOL-189 > URL: https://issues.apache.org/jira/browse/POOL-189 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: java 1.6.0_24 >Reporter: Adrian Nistor > Fix For: 1.5.7 > > Attachments: BUG-189v1.diff, Test.java > > > Hi, > When I call close() and borrowObject() concurrently with no objects in > the pool, close() will finish but borrowObject() is blocked forever. > The documentation of close() mentions that borrowObject() should fail > with IllegalStateException, so I would expect the waiting threads to > throw IllegalStateException. > I will attach a test that exposes this problem. For this test, the > expected output is: > 0 > 1 > 2 > ... > 4999 > DONE > But when the bug manifests (almost always for this test), the output > is: > 0 > 1 > 2 > The test does not finish, it just gets stuck after printing several > values. > Is this a bug or am I reading the documentation wrongly? Is there > a patch for this? > Thanks! > Adrian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-189) close() does not release threads blocked on borrowObject()
[ https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149674#comment-13149674 ] William R. Speirs commented on POOL-189: Created a patch which I think fixes this issue. When the close() method is called it goes through the _allocationQueue and notifies all of the waiting threads. Then in the barrowObject() method, there is a check to see if the pool is closed after a waiting thread wakes. If so, the thread throws an IllegalStateException with a message of "Pool closed". I also included a unit test which tests this bug. Note: I was working off /commons/proper/pool/branches/POOL_1_X as I couldn't find a branch explicitly for 1.5.x code, and I figured trunk was 2.x code. > close() does not release threads blocked on borrowObject() > -- > > Key: POOL-189 > URL: https://issues.apache.org/jira/browse/POOL-189 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: java 1.6.0_24 >Reporter: Adrian Nistor > Fix For: 1.5.7 > > Attachments: BUG-189v1.diff, Test.java > > > Hi, > When I call close() and borrowObject() concurrently with no objects in > the pool, close() will finish but borrowObject() is blocked forever. > The documentation of close() mentions that borrowObject() should fail > with IllegalStateException, so I would expect the waiting threads to > throw IllegalStateException. > I will attach a test that exposes this problem. For this test, the > expected output is: > 0 > 1 > 2 > ... > 4999 > DONE > But when the bug manifests (almost always for this test), the output > is: > 0 > 1 > 2 > The test does not finish, it just gets stuck after printing several > values. > Is this a bug or am I reading the documentation wrongly? Is there > a patch for this? > Thanks! > Adrian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-291) Add new function FileUtils.directoryContains
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149636#comment-13149636 ] Gary D. Gregory commented on IO-291: Committed revision 1201713. This is a simple implementation that seems to make the most sense to me. Please discuss. > Add new function FileUtils.directoryContains > > > Key: IO-291 > URL: https://issues.apache.org/jira/browse/IO-291 > Project: Commons IO > Issue Type: New Feature > Components: Utilities >Affects Versions: 2.1 >Reporter: Pier-Luc Caron St-Pierre >Assignee: Gary D. Gregory > Labels: patch > Fix For: 2.2 > > Attachments: io-291-simple.diff, io-291-v5.patch > > > I added a function that determines whether the specified leaf is contains by > the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-341) [NumberUtils] Please add number <> byte[] methods
[
https://issues.apache.org/jira/browse/LANG-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Ricard updated LANG-341:
Attachment: LANG-341-2.patch
Here is a patch with conversion methods for: short, int, float, long and double
(based on the previous patch of Henri).
Should we check the buffer length? (in addittion to the null checking)
Should we add other methods with a default value? (toPrimitive(byte[] buff,
primitive default))
> [NumberUtils] Please add number <> byte[] methods
> -
>
> Key: LANG-341
> URL: https://issues.apache.org/jira/browse/LANG-341
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.math.*
>Reporter: Lilianne E. Blaze
> Fix For: 3.x
>
> Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
> LANG-341.patch
>
>
> Hello,
> I need a set of methods to convert Long to or from a byte[] array, as if
> writing / reading from Data(Input/Output)Stream(
> ByteArray(Input/Output)Stream ).
> First, doing it with Streams seems a bit wasteful, second, it seems a
> pretty general use. Would it be possible to add something like that to,
> for example,
> org.apache.commons.lang.math.NumberUtils?
> Example code:
> static public long toLong(byte[] b)
> {
> return toLong(b, 0);
> }
>
> static public long toLong(byte[] b, int offset)
> {
> return (((long)b[offset] << 56) +
> ((long)(b[offset + 1] & 255) << 48) +
> ((long)(b[offset + 2] & 255) << 40) +
> ((long)(b[offset + 3] & 255) << 32) +
> ((long)(b[offset + 4] & 255) << 24) +
> ((b[offset + 5] & 255) << 16) +
> ((b[offset + 6] & 255) << 8) +
> ((b[offset + 7] & 255) << 0));
> }
>
> static public byte[] longToByteArray(long l)
> {
> byte b[] = new byte[8];
> longToByteArray(l, b, 0);
> return b;
> }
>
> static public void longToByteArray(long l, byte b[], int offset)
> {
> b[offset] = (byte)(l >>> 56);
> b[offset + 1] = (byte)(l >>> 48);
> b[offset + 2] = (byte)(l >>> 40);
> b[offset + 3] = (byte)(l >>> 32);
> b[offset + 4] = (byte)(l >>> 24);
> b[offset + 5] = (byte)(l >>> 16);
> b[offset + 6] = (byte)(l >>> 8);
> b[offset + 7] = (byte)(l >>> 0);
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLI-120) equals and hashCode are incomplete
[ https://issues.apache.org/jira/browse/CLI-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149576#comment-13149576 ] Andrew Shirley commented on CLI-120: Sounds good, Make sure that whenever you do implement them, they follow the rules outlined in the Javadoc on Object [1]. If you want a guide as to how to implement them properly, I would recommend the chapter on the subject from Effective Java By Joshua Bloch or have a look at what is produced by eclipse's "generate hashCode() and equals()" function (in the source menu). [1]: http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#hashCode() > equals and hashCode are incomplete > -- > > Key: CLI-120 > URL: https://issues.apache.org/jira/browse/CLI-120 > Project: Commons CLI > Issue Type: Improvement > Components: CLI-2.x >Reporter: Andrew Shirley >Priority: Minor > Fix For: 2.0 > > > there are many classes with equals and hashCode implemented however there are > also classes which don't. We need to be consistent and if we are using equals > then we need to define it for all classes in the affected hierarchy. For > example OptionImpl has an equals but ParentImpl which extends OptionImpl and > has several new members doesn't. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
