[jira] Commented: (LANG-456) HashCodeBuilder throws StackOverflowError in bidirectional navigable association
[ https://issues.apache.org/jira/browse/LANG-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791257#action_12791257 ] Henri Yandell commented on LANG-456: From LANG-459 - question of whether we should start using IdentityHashMap and removing the IDKey class. Is the fix here to extend the register concept to all parts of the builder package? HashCodeBuilder throws StackOverflowError in bidirectional navigable association Key: LANG-456 URL: https://issues.apache.org/jira/browse/LANG-456 Project: Commons Lang Issue Type: Bug Affects Versions: 2.4 Environment: Widows XP. Sun JDK 1.5 or 1.6. Reporter: Bob Fields Fix For: 3.0 Attachments: HashCodeBuilderStackOverflow.zip, StackOverflowError.zip This is not the reflection methods, it is the regular HashCodeBuilder append methods. It causes EqualsBuilder, ToStringBuilder, CompareToBuilder to also throw the StackOverflowException, but those methods work when one of the HashCodeBuilder bidirectional association attributes .hashCode() is commented out. The problem is that all of the builders call registerObject() which creates a hashCode, but only the reflectionAppend method checks if an object is registered. Bi-directional associations are a very common pattern in Jaxb and Hibernate. In this case, I generate code from a model in order to avoid the reflection penalty - I already know what the attributes are at compile time, so I use .append instead of .reflectionAppend. See attached example + unit test. One side of the bidirectional association must be commented out in the hashCode method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-397) RegexpUtils?
[ https://issues.apache.org/jira/browse/LANG-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-397. -- Resolution: Later No need for a placeholder for unknown new features. RegexpUtils? Key: LANG-397 URL: https://issues.apache.org/jira/browse/LANG-397 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Fix For: 3.x Consider whether we can add any value to the Regexp libraries. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-316) Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder
[ https://issues.apache.org/jira/browse/LANG-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791274#action_12791274 ] Stephen Colebourne commented on LANG-316: - I don't like this idea for the reasons Hen has found. The equalsIgnoreCase implementation is complex and hash code would be messed up. Its also a feature I've never needed. Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder - Key: LANG-316 URL: https://issues.apache.org/jira/browse/LANG-316 Project: Commons Lang Issue Type: New Feature Components: lang.builder.* Affects Versions: 2.3 Environment: Any Reporter: Nelson Carpentier Priority: Minor Fix For: 3.0 Attachments: lang_20070206.diff, lang_20070529.diff Sometimes I want a String property containing ThisString to be seen as equal to THISstring. EqualsBuilder (and HashCodeBuilder) should be enhanced to optionally handle this requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (NET-304) TFTP send method having issue
TFTP send method having issue - Key: NET-304 URL: https://issues.apache.org/jira/browse/NET-304 Project: Commons Net Issue Type: Bug Affects Versions: 2.0 Reporter: Rahul Pujari Priority: Minor I am using commons net 2.0 version. I have a TFTP server implemented and the scenario is below - 1) Client sends TFTPWrite request. 2) Server sends DATA packet, client sends ACK. Server receives it (thr TFTP.receive()). 3) This goes well for quite some time. 4) Now server gets same ACK thrice, means some packets are not reached to client and client sends the same ACK again. 5) Server also sends the old DATA packet coresponding to the ACK, using TFTP.send(). But somehow those DATA packets are not seen on the interface in the snoop log :(. So client has a timeout of say 5 secs, and closes the connection at its end indicating overall transfer failure. And I could see the DATA packet coming in the snoop log after 13-14 secs of delay :(, once TFTP.send() is invoked. This does not happens always. Scenario works fine most of the times, but there are cases where it's delaying sending the packet on the i/f. And delay osberved was around 10 secs. Because of this, Client closes a connection :(. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-398) Annotations?
[ https://issues.apache.org/jira/browse/LANG-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791330#action_12791330 ] Sebb commented on LANG-398: --- Note: As implemented, the JCIP annotations have type Retention.RUNTIME, which means that the annotation jar is needed at runtime. Not sure we want that. It's a pity they aren't Retention.CLASS, which would still allow static analysis tools such as Findbugs to use them. Annotations? Key: LANG-398 URL: https://issues.apache.org/jira/browse/LANG-398 Project: Commons Lang Issue Type: Task Reporter: Henri Yandell Fix For: 3.x Any 'should be standard' annotations that people would like to see in Lang? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-323) Add Semivariance calculation
[ https://issues.apache.org/jira/browse/MATH-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791336#action_12791336 ] Phil Steitz commented on MATH-323: -- Looks like a good addition to me. Will complete review and commit (possibly with some mods) this weekend assuming others are OK with the addition. Add Semivariance calculation Key: MATH-323 URL: https://issues.apache.org/jira/browse/MATH-323 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: Larry Diamond Priority: Minor Fix For: 2.1 Attachments: patch.txt, StatUtils.java, StatUtilsTest.java I've added semivariance calculations to my local build of commons-math and I would like to contribute them. Semivariance is described a little bit on http://en.wikipedia.org/wiki/Semivariance , but a real reason you would use them is in finance in order to compute the Sortino ratio rather than the Sharpe ratio. http://en.wikipedia.org/wiki/Sortino_ratio gives an explanation of the Sortino ratio and why you would choose to use that rather than the Sharpe ratio. (There are other ways to measure the performance of your portfolio, but I wont bore everybody with that stuff) I've already got the coding completed along with the test cases and building using mvn site. The only two files I've modified is src/main/java/org/apache/commons/stat/StatUtils.java and src/test/java/org/apache/commons/math/stat/StatUtilsTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-316) Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder
[ https://issues.apache.org/jira/browse/LANG-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791376#action_12791376 ] Paul Benedict commented on LANG-316: But I think you guys both missed my point. I do it all the time anyway. It doesn't mess up the hash code when you're contract is correct. If equals() has to ignore case, so does hashCode() -- and you do that by contracting how you want them to work. Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder - Key: LANG-316 URL: https://issues.apache.org/jira/browse/LANG-316 Project: Commons Lang Issue Type: New Feature Components: lang.builder.* Affects Versions: 2.3 Environment: Any Reporter: Nelson Carpentier Priority: Minor Fix For: 3.0 Attachments: lang_20070206.diff, lang_20070529.diff Sometimes I want a String property containing ThisString to be seen as equal to THISstring. EqualsBuilder (and HashCodeBuilder) should be enhanced to optionally handle this requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-316) Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder
[ https://issues.apache.org/jira/browse/LANG-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791381#action_12791381 ] Sebb commented on LANG-316: --- Can't one just sub-class the Builders and override the append(Object) or append(Object, Object) method? This does depend on the implementation (i.e. String has to be processed as an Object), but it requires no code change to LANG. To make it simpler, perhaps overridable append(String[,String]) methods could be added for this purpose. Otherwise, any implementation is going to need some way of specifying the Locale as well as the up/down direction, etc. and it will be hard to make it flexible. Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder - Key: LANG-316 URL: https://issues.apache.org/jira/browse/LANG-316 Project: Commons Lang Issue Type: New Feature Components: lang.builder.* Affects Versions: 2.3 Environment: Any Reporter: Nelson Carpentier Priority: Minor Fix For: 3.0 Attachments: lang_20070206.diff, lang_20070529.diff Sometimes I want a String property containing ThisString to be seen as equal to THISstring. EqualsBuilder (and HashCodeBuilder) should be enhanced to optionally handle this requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-567) ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed types very well
ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed types very well Key: LANG-567 URL: https://issues.apache.org/jira/browse/LANG-567 Project: Commons Lang Issue Type: Bug Components: lang.* Reporter: Sebb Fix For: 3.0 ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed array types very well. The stack trace for ArrayUtils.addAll(stringArray1, new Object()) starts: java.lang.ArrayStoreException at java.lang.System.arraycopy(Native Method) at org.apache.commons.lang3.ArrayUtils.addAll(ArrayUtils.java:2962) which is not all that obvious. Unfortunately the type parameters aren't checked (because the method is static) unless one uses: ArrayUtils.StringaddAll(stringArray1, new Object()) which it seems unlikely anyone would use. Might be better just to use Object and check the types at run-time? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-569) Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils
Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils -- Key: LANG-569 URL: https://issues.apache.org/jira/browse/LANG-569 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.4 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-568) @SuppressWarnings(unchecked) is used too generally
@SuppressWarnings(unchecked) is used too generally Key: LANG-568 URL: https://issues.apache.org/jira/browse/LANG-568 Project: Commons Lang Issue Type: Bug Components: General Reporter: Sebb Fix For: 3.0 @SuppressWarnings(unchecked) is used in several places on entire methods. Mostly there is no documentation as to why it is safe to ignore the warnings. Seems to me the annotation should be used as close as possible to the site of the warning, and the reason should be documented, so it can be revisited if there is a code change later. In fact, at least one of the warnings is NOT safe to ignore: ArrayUtils.Stringadd((String[])null, null); generates a ClassCastException, which should not happen if the warning is OK to ignore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-316) Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder
[ https://issues.apache.org/jira/browse/LANG-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791402#action_12791402 ] Paul Benedict commented on LANG-316: Sebb, I don't think the Locale is relevant for Commons Lang. Not every character has an upper/lower equivalent, but String should already know this because of Unicode's mapping -- it should already be addressed inside of String's toLowerCase() and toUpperCase(). Enable CaseInsensitivity in EqualsBuilder and HashCodeBuilder - Key: LANG-316 URL: https://issues.apache.org/jira/browse/LANG-316 Project: Commons Lang Issue Type: New Feature Components: lang.builder.* Affects Versions: 2.3 Environment: Any Reporter: Nelson Carpentier Priority: Minor Fix For: 3.0 Attachments: lang_20070206.diff, lang_20070529.diff Sometimes I want a String property containing ThisString to be seen as equal to THISstring. EqualsBuilder (and HashCodeBuilder) should be enhanced to optionally handle this requirement. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-569) Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils
[ https://issues.apache.org/jira/browse/LANG-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated LANG-569: - Attachment: LANG-569-v1.patch Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils -- Key: LANG-569 URL: https://issues.apache.org/jira/browse/LANG-569 Project: Commons Lang Issue Type: New Feature Affects Versions: 2.4 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-569-v1.patch Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-568) @SuppressWarnings(unchecked) is used too generally
[ https://issues.apache.org/jira/browse/LANG-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated LANG-568: -- Description: @SuppressWarnings(unchecked) is used in several places on entire methods. Mostly there is no documentation as to why it is safe to ignore the warnings. Seems to me the annotation should be used as close as possible to the site of the warning, and the reason should be documented, so it can be revisited if there is a code change later. In fact, at least one of the warnings is NOT safe to ignore: String[] s = ArrayUtils.add((String[])null, null); generates a ClassCastException, which should not happen if the warning is OK to ignore. was: @SuppressWarnings(unchecked) is used in several places on entire methods. Mostly there is no documentation as to why it is safe to ignore the warnings. Seems to me the annotation should be used as close as possible to the site of the warning, and the reason should be documented, so it can be revisited if there is a code change later. In fact, at least one of the warnings is NOT safe to ignore: ArrayUtils.Stringadd((String[])null, null); generates a ClassCastException, which should not happen if the warning is OK to ignore. @SuppressWarnings(unchecked) is used too generally Key: LANG-568 URL: https://issues.apache.org/jira/browse/LANG-568 Project: Commons Lang Issue Type: Bug Components: General Reporter: Sebb Fix For: 3.0 @SuppressWarnings(unchecked) is used in several places on entire methods. Mostly there is no documentation as to why it is safe to ignore the warnings. Seems to me the annotation should be used as close as possible to the site of the warning, and the reason should be documented, so it can be revisited if there is a code change later. In fact, at least one of the warnings is NOT safe to ignore: String[] s = ArrayUtils.add((String[])null, null); generates a ClassCastException, which should not happen if the warning is OK to ignore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-567) ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed types very well
[
https://issues.apache.org/jira/browse/LANG-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated LANG-567:
--
Description:
ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed array types
very well.
The stack trace for
Number[] st = ArrayUtils.addAll(new Integer[]{1}, new Long[]{2L});
starts:
java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at org.apache.commons.lang3.ArrayUtils.addAll(ArrayUtils.java:2962)
which is not all that obvious.
It would be a lot clearer if the method threw an IlegalArgumentException or
similar.
was:
ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed array types
very well.
The stack trace for ArrayUtils.addAll(stringArray1, new Object()) starts:
java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at org.apache.commons.lang3.ArrayUtils.addAll(ArrayUtils.java:2962)
which is not all that obvious.
Unfortunately the type parameters aren't checked (because the method is static)
unless one uses:
ArrayUtils.StringaddAll(stringArray1, new Object())
which it seems unlikely anyone would use.
Might be better just to use Object and check the types at run-time?
Better example
ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed types very
well
Key: LANG-567
URL: https://issues.apache.org/jira/browse/LANG-567
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Reporter: Sebb
Fix For: 3.0
ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed array types
very well.
The stack trace for
Number[] st = ArrayUtils.addAll(new Integer[]{1}, new Long[]{2L});
starts:
java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at org.apache.commons.lang3.ArrayUtils.addAll(ArrayUtils.java:2962)
which is not all that obvious.
It would be a lot clearer if the method threw an IlegalArgumentException or
similar.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-323) Add Semivariance calculation
[ https://issues.apache.org/jira/browse/MATH-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791454#action_12791454 ] Larry Diamond commented on MATH-323: Oh my this is embarrassing. You're right Luc. I messed up the algo when copying it from my source. When computing the Sortino ratio, you're eliminating the losses - so the code is correct for the Sortino ratio but is not truly semivariance. For anything below the mean, you should replace the value with the mean for the original distribution. I had zero adjusted the distribution before I called the method. I'll do a rewrite on this code and reattach it to this issue. Thank you for reviewing the code! I am so embarrassed! Add Semivariance calculation Key: MATH-323 URL: https://issues.apache.org/jira/browse/MATH-323 Project: Commons Math Issue Type: New Feature Affects Versions: 2.1 Reporter: Larry Diamond Assignee: Phil Steitz Priority: Minor Fix For: 2.1 Attachments: patch.txt, StatUtils.java, StatUtilsTest.java I've added semivariance calculations to my local build of commons-math and I would like to contribute them. Semivariance is described a little bit on http://en.wikipedia.org/wiki/Semivariance , but a real reason you would use them is in finance in order to compute the Sortino ratio rather than the Sharpe ratio. http://en.wikipedia.org/wiki/Sortino_ratio gives an explanation of the Sortino ratio and why you would choose to use that rather than the Sharpe ratio. (There are other ways to measure the performance of your portfolio, but I wont bore everybody with that stuff) I've already got the coding completed along with the test cases and building using mvn site. The only two files I've modified is src/main/java/org/apache/commons/stat/StatUtils.java and src/test/java/org/apache/commons/math/stat/StatUtilsTest.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-570) Do the test cases really still require main() and suite() methods?
Do the test cases really still require main() and suite() methods? -- Key: LANG-570 URL: https://issues.apache.org/jira/browse/LANG-570 Project: Commons Lang Issue Type: Improvement Components: General Reporter: Sebb Priority: Minor Fix For: 3.0 Do the test cases really still require main() and suite() methods? Unless the suite is being used to sequence some tests, it's just unnecessary clutter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (POOL-154) GenericObjectPool.close() JavaDoc incorrectly claims method does not call clear()
GenericObjectPool.close() JavaDoc incorrectly claims method does not call clear() - Key: POOL-154 URL: https://issues.apache.org/jira/browse/POOL-154 Project: Commons Pool Issue Type: Bug Affects Versions: Nightly Builds Reporter: Glen Mazza Priority: Minor The JavaDoc for GenericObjectPool.close() needs updating--contrary to the JavaDoc text, it *is* calling clear(). See here: http://svn.apache.org/viewvc/commons/proper/pool/trunk/src/java/org/apache/commons/pool/impl/GenericObjectPool.java?revision=831698view=markup#l1426 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DBCP-312) BasicDataSource.close() method needs JavaDoc clarification
BasicDataSource.close() method needs JavaDoc clarification -- Key: DBCP-312 URL: https://issues.apache.org/jira/browse/DBCP-312 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.3 Reporter: Glen Mazza Priority: Minor Hello, the JavaDoc could use clarification for the BasicDataSource.close() method. Link: http://commons.apache.org/dbcp/apidocs/org/apache/commons/dbcp/BasicDataSource.html#close() Text: Close and release all connections that are currently stored in the connection pool associated with our data source. All open (active) connection remain open until closed. Once the data source has been closed, no more connections can be obtained. I'm unsure if this method closes just idle, or both idle and active connections. This is a important distinction, because you wouldn't want to call close() if you still have some needed active connections open on various threads. The first sentence seems to indicate both active and idle threads will be closed, but the second sentence indicates that only the idle threads will be explicitly closed. Recommend changing text to: Close and release all connections, whether active or idle, that are currently stored in the connection pool associated with our data source. Once the data source has been closed, no more connections can be obtained. or (if this method closes just idle connections): Close and release all idle connections that are currently stored in the connection pool associated with our data source. All open (active) connections will still remain open until they are closed via the Connection close() method. Once the data source has been closed, no more connections can be obtained. Note that, for the latter case, if BasicDataSource.close() only closes and releases idle connections, and an active DBCP Connection object subsequently has its close() method called, it's not clear whether its underlying actual JDBC connection will be released. I.e., how do you release JDBC connections on previously active DBCP Connections after BasicDataSource.close() is called? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-570) Do the test cases really still require main() and suite() methods?
[ https://issues.apache.org/jira/browse/LANG-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791758#action_12791758 ] Henri Yandell commented on LANG-570: Not afaik. Also they don't need constructors or setUp/tearDown when empty. Do the test cases really still require main() and suite() methods? -- Key: LANG-570 URL: https://issues.apache.org/jira/browse/LANG-570 Project: Commons Lang Issue Type: Improvement Components: General Reporter: Sebb Priority: Minor Fix For: 3.0 Do the test cases really still require main() and suite() methods? Unless the suite is being used to sequence some tests, it's just unnecessary clutter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-567) ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed types very well
[
https://issues.apache.org/jira/browse/LANG-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791759#action_12791759
]
Henri Yandell commented on LANG-567:
+1
ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed types very
well
Key: LANG-567
URL: https://issues.apache.org/jira/browse/LANG-567
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Reporter: Sebb
Fix For: 3.0
ArrayUtils.addAll(T[] array1, T... array2) does not handle mixed array types
very well.
The stack trace for
Number[] st = ArrayUtils.addAll(new Integer[]{1}, new Long[]{2L});
starts:
java.lang.ArrayStoreException
at java.lang.System.arraycopy(Native Method)
at org.apache.commons.lang3.ArrayUtils.addAll(ArrayUtils.java:2962)
which is not all that obvious.
It would be a lot clearer if the method threw an IlegalArgumentException or
similar.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-568) @SuppressWarnings(unchecked) is used too generally
[ https://issues.apache.org/jira/browse/LANG-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791762#action_12791762 ] Henri Yandell commented on LANG-568: Seems good. I count 11 in the main source, so not that painful to fix. ./ArrayUtils.java:@SuppressWarnings(unchecked) ./ArrayUtils.java:@SuppressWarnings(unchecked) ./ArrayUtils.java:@SuppressWarnings(unchecked) ./ArrayUtils.java:@SuppressWarnings(unchecked) ./ArrayUtils.java:@SuppressWarnings(unchecked) ./builder/CompareToBuilder.java:@SuppressWarnings(unchecked) ./Range.java:@SuppressWarnings(unchecked) // OK because we checked the class above ./Range.java:@SuppressWarnings(unchecked) ./Range.java:@SuppressWarnings(unchecked) ./text/StrBuilder.java:@SuppressWarnings(null) // str cannot be null ./text/StrLookup.java:@SuppressWarnings(unchecked) // System property keys and values are always Strings @SuppressWarnings(unchecked) is used too generally Key: LANG-568 URL: https://issues.apache.org/jira/browse/LANG-568 Project: Commons Lang Issue Type: Bug Components: General Reporter: Sebb Fix For: 3.0 @SuppressWarnings(unchecked) is used in several places on entire methods. Mostly there is no documentation as to why it is safe to ignore the warnings. Seems to me the annotation should be used as close as possible to the site of the warning, and the reason should be documented, so it can be revisited if there is a code change later. In fact, at least one of the warnings is NOT safe to ignore: String[] s = ArrayUtils.add((String[])null, null); generates a ClassCastException, which should not happen if the warning is OK to ignore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-569) Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils
[ https://issues.apache.org/jira/browse/LANG-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed LANG-569. -- Resolution: Fixed Thanks Niall. svn ci -m Applying Niall's patch from LANG-569 adding indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils src Sendingsrc/java/org/apache/commons/lang3/StringUtils.java Sending src/test/org/apache/commons/lang3/StringUtilsEqualsIndexOfTest.java Transmitting file data .. Committed revision 891528. Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils -- Key: LANG-569 URL: https://issues.apache.org/jira/browse/LANG-569 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.4 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-569-v1.patch Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-569) Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils
[ https://issues.apache.org/jira/browse/LANG-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-569: --- Component/s: lang.* Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils -- Key: LANG-569 URL: https://issues.apache.org/jira/browse/LANG-569 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.4 Reporter: Niall Pemberton Priority: Minor Fix For: 3.0 Attachments: LANG-569-v1.patch Add indexOfIgnoreCase() and lastIndexOfIgnoreCase() methods to StringUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-398) Annotations?
[ https://issues.apache.org/jira/browse/LANG-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-398: --- Component/s: General Annotations? Key: LANG-398 URL: https://issues.apache.org/jira/browse/LANG-398 Project: Commons Lang Issue Type: Task Components: General Reporter: Henri Yandell Fix For: 3.x Any 'should be standard' annotations that people would like to see in Lang? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-538) DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791798#action_12791798
]
Henri Yandell commented on LANG-538:
I think this is due to FastDateFormat's:
if (mTimeZoneForced) {
calendar = (Calendar) calendar.clone();
calendar.setTimeZone(mTimeZone);
}
If I call getTime() before that, then the code works. If however I wait until
after that to call getTime(), it does not work. The calendar before and after
report themselves to be equal, and their toString contains the same information
in both cases, yet something must not be getting lazy-initialized and then lost
in the clone.
DateFormatUtils.format does not correctly change Calendar TimeZone in certain
situations
Key: LANG-538
URL: https://issues.apache.org/jira/browse/LANG-538
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.4
Environment: Sun JDK6, RHEL 5.3
Reporter: Jeff Peterson
Fix For: 3.0
If a Calendar object is constructed in certain ways a call to
Calendar.setTimeZone does not correctly change the Calendars fields. Calling
Calenar.getTime() seems to fix this problem. While this is probably a bug in
the JDK, it would be nice if DateFormatUtils was smart enough to
detect/resolve this problem.
For example, the following unit test fails:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
// more commonly constructed with: cal = new GregorianCalendar(2009, 9,
16, 8, 42, 16)
// for the unit test to work in any time zone, constructing with GMT-8
rather than default locale time zone
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
However, this unit test passes:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-538) DateFormatUtils.format does not correctly change Calendar TimeZone in certain situations
[
https://issues.apache.org/jira/browse/LANG-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-538.
--
Resolution: Fixed
Thanks for the report Jeff. I've inserted a getTime() into FastDateFormat that
fixes your test case, and hopefully extends to the general problem.
svn ci -m Fixing LANG-538 - you need to call getTime() on a calendar sometimes
to get it in the right state, otherwise the timezone gets out of whack. src
Sendingsrc/java/org/apache/commons/lang3/time/FastDateFormat.java
Sendingsrc/test/org/apache/commons/lang3/time/FastDateFormatTest.java
Transmitting file data ..
Committed revision 891542.
DateFormatUtils.format does not correctly change Calendar TimeZone in certain
situations
Key: LANG-538
URL: https://issues.apache.org/jira/browse/LANG-538
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.4
Environment: Sun JDK6, RHEL 5.3
Reporter: Jeff Peterson
Fix For: 3.0
If a Calendar object is constructed in certain ways a call to
Calendar.setTimeZone does not correctly change the Calendars fields. Calling
Calenar.getTime() seems to fix this problem. While this is probably a bug in
the JDK, it would be nice if DateFormatUtils was smart enough to
detect/resolve this problem.
For example, the following unit test fails:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
// more commonly constructed with: cal = new GregorianCalendar(2009, 9,
16, 8, 42, 16)
// for the unit test to work in any time zone, constructing with GMT-8
rather than default locale time zone
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
However, this unit test passes:
{noformat}
public void testFormat_CalendarIsoMsZulu() {
final String dateTime = 2009-10-16T16:42:16.000Z;
GregorianCalendar cal = new
GregorianCalendar(TimeZone.getTimeZone(GMT-8));
cal.clear();
cal.set(2009, 9, 16, 8, 42, 16);
cal.getTime();
FastDateFormat format =
FastDateFormat.getInstance(-MM-dd'T'HH:mm:ss.SSS'Z',
TimeZone.getTimeZone(GMT));
assertEquals(dateTime, dateTime, format.format(cal));
}
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-530) parseDate cannot parse ISO8601 dates produced by FastDateFormat
[
https://issues.apache.org/jira/browse/LANG-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791811#action_12791811
]
Henri Yandell commented on LANG-530:
No simple matter to parse the ZZ and then send the code on to
SimpleDateFormat.parseObject.
Definitely an option to point DateUtils to FastDateFormat and have an exception
thrown if TimeZoneNumberRule.INSTANCE.COLON is in the pattern. Potential
downside - FastDateFormat maintains a static cache of patterns used and we'd be
exposing DateUtils users to that memory usage.
Another option is to modify the incoming String to not have the ':'. Either in
DateUtils, or as it's a better fit, in the same code as above but with the
modification instead of the exception. Downside is who knows what's in the
pattern's literals.
A meld of the two:
Switch to FastDateFormat
If the pattern in use equals one of DateFormatUtils' ones, then use regexp.
Otherwise throw exception.
parseDate cannot parse ISO8601 dates produced by FastDateFormat
---
Key: LANG-530
URL: https://issues.apache.org/jira/browse/LANG-530
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.4
Reporter: Aaron Zeckoski
Fix For: 3.0
I cannot see why this is failing but here is my code:
Date parseDate(String dateStr) {
Date d = null;
if (dateStr != null ! .equals(dateStr)) {
try {
// try to parse the date from ISO8601, general
formats, and RFC-2822
d = DateUtils.parseDate(dateStr, new String[] {
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern()
});
} catch (ParseException e) {
// nothing to do
log.info(Failed to parse: + dateStr + : + e, e);
d = null;
}
}
return d;
}
The string I am sending in to that method was generated like this:
String isoDateStr =
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(date);
The exception is:
2009-09-03 13:29:37,644 [399355...@qtp3-2] INFO
search.SOLRSearchService - Failed to parse:
2009-09-03T13:29:30+01:00:java.text.ParseException: Unable to parse
the date: 2009-09-03T13:29:30+01:00
java.text.ParseException: Unable to parse the date: 2009-09-03T13:29:30+01:00
at org.apache.commons.lang.time.DateUtils.parseDate(DateUtils.java:285)
at
org.steeple.impl.search.SOLRSearchService.parseDate(SOLRSearchService.java:412)
at
org.steeple.impl.search.SOLRSearchService.execute(SOLRSearchService.java:311)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-530) parseDate cannot parse ISO8601 dates produced by FastDateFormat
[
https://issues.apache.org/jira/browse/LANG-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-530:
---
Attachment: LANG-530-exception.patch
Patch attached showing exception throwing option.
parseDate cannot parse ISO8601 dates produced by FastDateFormat
---
Key: LANG-530
URL: https://issues.apache.org/jira/browse/LANG-530
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.4
Reporter: Aaron Zeckoski
Fix For: 3.0
Attachments: LANG-530-exception.patch
I cannot see why this is failing but here is my code:
Date parseDate(String dateStr) {
Date d = null;
if (dateStr != null ! .equals(dateStr)) {
try {
// try to parse the date from ISO8601, general
formats, and RFC-2822
d = DateUtils.parseDate(dateStr, new String[] {
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern()
});
} catch (ParseException e) {
// nothing to do
log.info(Failed to parse: + dateStr + : + e, e);
d = null;
}
}
return d;
}
The string I am sending in to that method was generated like this:
String isoDateStr =
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(date);
The exception is:
2009-09-03 13:29:37,644 [399355...@qtp3-2] INFO
search.SOLRSearchService - Failed to parse:
2009-09-03T13:29:30+01:00:java.text.ParseException: Unable to parse
the date: 2009-09-03T13:29:30+01:00
java.text.ParseException: Unable to parse the date: 2009-09-03T13:29:30+01:00
at org.apache.commons.lang.time.DateUtils.parseDate(DateUtils.java:285)
at
org.steeple.impl.search.SOLRSearchService.parseDate(SOLRSearchService.java:412)
at
org.steeple.impl.search.SOLRSearchService.execute(SOLRSearchService.java:311)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-530) parseDate cannot parse ISO8601 dates produced by FastDateFormat
[
https://issues.apache.org/jira/browse/LANG-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791812#action_12791812
]
Henri Yandell commented on LANG-530:
Suggested regexp: str.replaceAll(([-+][0-9][0-9]):([0-9][0-9]), $1$2);
parseDate cannot parse ISO8601 dates produced by FastDateFormat
---
Key: LANG-530
URL: https://issues.apache.org/jira/browse/LANG-530
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.4
Reporter: Aaron Zeckoski
Fix For: 3.0
Attachments: LANG-530-exception.patch
I cannot see why this is failing but here is my code:
Date parseDate(String dateStr) {
Date d = null;
if (dateStr != null ! .equals(dateStr)) {
try {
// try to parse the date from ISO8601, general
formats, and RFC-2822
d = DateUtils.parseDate(dateStr, new String[] {
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern()
});
} catch (ParseException e) {
// nothing to do
log.info(Failed to parse: + dateStr + : + e, e);
d = null;
}
}
return d;
}
The string I am sending in to that method was generated like this:
String isoDateStr =
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(date);
The exception is:
2009-09-03 13:29:37,644 [399355...@qtp3-2] INFO
search.SOLRSearchService - Failed to parse:
2009-09-03T13:29:30+01:00:java.text.ParseException: Unable to parse
the date: 2009-09-03T13:29:30+01:00
java.text.ParseException: Unable to parse the date: 2009-09-03T13:29:30+01:00
at org.apache.commons.lang.time.DateUtils.parseDate(DateUtils.java:285)
at
org.steeple.impl.search.SOLRSearchService.parseDate(SOLRSearchService.java:412)
at
org.steeple.impl.search.SOLRSearchService.execute(SOLRSearchService.java:311)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-530) parseDate cannot parse ISO8601 dates produced by FastDateFormat
[
https://issues.apache.org/jira/browse/LANG-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791819#action_12791819
]
Henri Yandell commented on LANG-530:
Arbitrarily moving DateUtils to FastDateFormat concerns me. So does running
regexp on the user input. However I think the following will a) fix 80% of
issues and b) be safe:
if the pattern in question ends in ZZ, which all of the ones in DateFormatUtils
do, then go ahead and do the regexp. If it ends in ZZ, then it's not part of a
literal, so there's no concern for clash. There might be other ZZ's that don't
get fixed, but this will ensure the items in DateFormatUtils work and cover
another set of formats.
parseDate cannot parse ISO8601 dates produced by FastDateFormat
---
Key: LANG-530
URL: https://issues.apache.org/jira/browse/LANG-530
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.4
Reporter: Aaron Zeckoski
Fix For: 3.0
Attachments: LANG-530-exception.patch
I cannot see why this is failing but here is my code:
Date parseDate(String dateStr) {
Date d = null;
if (dateStr != null ! .equals(dateStr)) {
try {
// try to parse the date from ISO8601, general
formats, and RFC-2822
d = DateUtils.parseDate(dateStr, new String[] {
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern()
});
} catch (ParseException e) {
// nothing to do
log.info(Failed to parse: + dateStr + : + e, e);
d = null;
}
}
return d;
}
The string I am sending in to that method was generated like this:
String isoDateStr =
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(date);
The exception is:
2009-09-03 13:29:37,644 [399355...@qtp3-2] INFO
search.SOLRSearchService - Failed to parse:
2009-09-03T13:29:30+01:00:java.text.ParseException: Unable to parse
the date: 2009-09-03T13:29:30+01:00
java.text.ParseException: Unable to parse the date: 2009-09-03T13:29:30+01:00
at org.apache.commons.lang.time.DateUtils.parseDate(DateUtils.java:285)
at
org.steeple.impl.search.SOLRSearchService.parseDate(SOLRSearchService.java:412)
at
org.steeple.impl.search.SOLRSearchService.execute(SOLRSearchService.java:311)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-530) parseDate cannot parse ISO8601 dates produced by FastDateFormat
[
https://issues.apache.org/jira/browse/LANG-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-530:
---
Attachment: LANG-530-protect-SimpleDateFormat.patch
Attaching patch to protect SimpleDateFormat from ZZ as mentioned in previous
comment.
parseDate cannot parse ISO8601 dates produced by FastDateFormat
---
Key: LANG-530
URL: https://issues.apache.org/jira/browse/LANG-530
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.4
Reporter: Aaron Zeckoski
Fix For: 3.0
Attachments: LANG-530-exception.patch,
LANG-530-protect-SimpleDateFormat.patch
I cannot see why this is failing but here is my code:
Date parseDate(String dateStr) {
Date d = null;
if (dateStr != null ! .equals(dateStr)) {
try {
// try to parse the date from ISO8601, general
formats, and RFC-2822
d = DateUtils.parseDate(dateStr, new String[] {
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern()
});
} catch (ParseException e) {
// nothing to do
log.info(Failed to parse: + dateStr + : + e, e);
d = null;
}
}
return d;
}
The string I am sending in to that method was generated like this:
String isoDateStr =
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(date);
The exception is:
2009-09-03 13:29:37,644 [399355...@qtp3-2] INFO
search.SOLRSearchService - Failed to parse:
2009-09-03T13:29:30+01:00:java.text.ParseException: Unable to parse
the date: 2009-09-03T13:29:30+01:00
java.text.ParseException: Unable to parse the date: 2009-09-03T13:29:30+01:00
at org.apache.commons.lang.time.DateUtils.parseDate(DateUtils.java:285)
at
org.steeple.impl.search.SOLRSearchService.parseDate(SOLRSearchService.java:412)
at
org.steeple.impl.search.SOLRSearchService.execute(SOLRSearchService.java:311)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (LANG-530) parseDate cannot parse ISO8601 dates produced by FastDateFormat
[
https://issues.apache.org/jira/browse/LANG-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-530.
--
Resolution: Fixed
Applying the least worst of the various suggestions I've come up with :)
svn ci -m Applying 'fix' for LANG-530. DateUtils.parseDate now protects the
common use case of FastDateFormat ZZ output, namely ZZ on the end of the
pattern, from being passed to SimpleDateFormat as is. Use of ZZ elsewhere in
the pattern isn't protected and will want to consider emulating the String
changes made in this patch.
Sendingsrc/java/org/apache/commons/lang3/time/DateUtils.java
Sendingsrc/test/org/apache/commons/lang3/time/DateUtilsTest.java
Transmitting file data ..
Committed revision 891572.
parseDate cannot parse ISO8601 dates produced by FastDateFormat
---
Key: LANG-530
URL: https://issues.apache.org/jira/browse/LANG-530
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.4
Reporter: Aaron Zeckoski
Fix For: 3.0
Attachments: LANG-530-exception.patch,
LANG-530-protect-SimpleDateFormat.patch
I cannot see why this is failing but here is my code:
Date parseDate(String dateStr) {
Date d = null;
if (dateStr != null ! .equals(dateStr)) {
try {
// try to parse the date from ISO8601, general
formats, and RFC-2822
d = DateUtils.parseDate(dateStr, new String[] {
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern()
});
} catch (ParseException e) {
// nothing to do
log.info(Failed to parse: + dateStr + : + e, e);
d = null;
}
}
return d;
}
The string I am sending in to that method was generated like this:
String isoDateStr =
DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(date);
The exception is:
2009-09-03 13:29:37,644 [399355...@qtp3-2] INFO
search.SOLRSearchService - Failed to parse:
2009-09-03T13:29:30+01:00:java.text.ParseException: Unable to parse
the date: 2009-09-03T13:29:30+01:00
java.text.ParseException: Unable to parse the date: 2009-09-03T13:29:30+01:00
at org.apache.commons.lang.time.DateUtils.parseDate(DateUtils.java:285)
at
org.steeple.impl.search.SOLRSearchService.parseDate(SOLRSearchService.java:412)
at
org.steeple.impl.search.SOLRSearchService.execute(SOLRSearchService.java:311)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-462) FastDateFormat supports parse
[ https://issues.apache.org/jira/browse/LANG-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791827#action_12791827 ] Henri Yandell commented on LANG-462: Note that LANG-530 led to DateUtils.parseDate allowing for the ISO8601 time zone to be parsed when it appears on the end of the pattern. FastDateFormat supports parse - Key: LANG-462 URL: https://issues.apache.org/jira/browse/LANG-462 Project: Commons Lang Issue Type: New Feature Components: lang.time.* Reporter: Franz Wong Fix For: 3.x Currently FastDateFormat only supports formatting the ISO8601 time zone, however, it doesn't support parsing such string to Date. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-396) Investigate for vararg usages
[ https://issues.apache.org/jira/browse/LANG-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12791828#action_12791828 ] Henri Yandell commented on LANG-396: DateUtils.parseDate should take a vararg String... of patterns. Investigate for vararg usages - Key: LANG-396 URL: https://issues.apache.org/jira/browse/LANG-396 Project: Commons Lang Issue Type: Task Components: General Reporter: Henri Yandell Fix For: 3.0 Attachments: VarargsCandidates.java Which methods are good candidates for varargs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
