date:20140516


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Labels: java8 jdk8  (was: )

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x
 {code}
 org.apache.commons.collections.MultiHashMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (SANDBOX-476) [asm] IllegalStateException: Undefined label used with ASM 4.1

2014-05-16 Thread Alexandre Chatiron (JIRA)


 [ 
https://issues.apache.org/jira/browse/SANDBOX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexandre Chatiron updated SANDBOX-476:
---

Attachment: javaflow-asm5.02.patch

Ok I fix it, all tests are green with ASM 5.0.2

 [asm] IllegalStateException: Undefined label used with ASM  4.1
 --

 Key: SANDBOX-476
 URL: https://issues.apache.org/jira/browse/SANDBOX-476
 Project: Commons Sandbox
  Issue Type: Bug
  Components: Javaflow
Affects Versions: Nightly Builds
Reporter: Alexandre Chatiron
  Labels: asm, label
 Attachments: BytecodeClassLoader.java, ContinuationClassAdapter.java, 
 ContinuationMethodAdapter.java, ContinuationMethodAnalyzer.java, 
 javaflow-asm5.02.patch, pom.xml


 I want to upgrade Commons Javaflow  from ASM 4 to 5 (same problem with 4.1 ) 
 and I get this exception:
 {code}
 java.lang.IllegalStateException: Undefined label used
 at org.objectweb.asm.util.CheckMethodAdapter.visitMaxs(Unknown Source)
 at
 org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAdapter.visitMaxs(ContinuationMethodAdapter.java:313)
 at org.objectweb.asm.tree.MethodNode.accept(Unknown Source)
 at
 org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAnalyzer.visitEnd(ContinuationMethodAnalyzer.java:140)
 {code} 
 the code triggering this error is:
 {code:java}
 public void visitMaxs(int maxStack, int maxLocals) {
 Label endLabel = new Label();
 mv.visitLabel(endLabel);
 mv.visitLocalVariable(__stackRecorder, L + STACK_RECORDER + ;, 
 null, startLabel, endLabel, stackRecorderVar);
 mv.visitMaxs(0, 0);
 }
 {code}
 Any idea how to fix that?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (COLLECTIONS-529) Add removeAll(CollectionE collection, CollectionE remove, ComparatorE comparator) and contains(CollectionE collection, E object, ComparatorE comparator) me

2014-05-16 Thread Alexander Muthmann (JIRA)

Alexander Muthmann created COLLECTIONS-529:
--

 Summary: Add removeAll(CollectionE collection, CollectionE 
remove, ComparatorE comparator) and contains(CollectionE collection, E 
object, ComparatorE comparator) methods
 Key: COLLECTIONS-529
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-529
 Project: Commons Collections
  Issue Type: Improvement
  Components: Collection
Reporter: Alexander Muthmann


Hi,

this request originates from one of our project where we have implemented 
something similar.

The Java-Interface java.util.CollectionE specifies the two methods 
contains(Object o) and boolean removeAll(Collection? c). Both methods rely on 
the equals() method of the given Objects.

In some cases, it's not possible to change those methods and therefore 
removeAll and contains cannot be used directly. 

E.g. if you have an class myClass with property A and B and the equals method 
uses both properties, but you are only interested in property B.

To solve this problem, I'd like to propose the following extensions of 
CollectionsUtils:

{code}
/**
 * Removes all elements of remove from the collection using the comparator 
instead of .equals()
 */
public static E CollectionE removeAll(final CollectionE collection, final 
CollectionE remove, ComparatorE comparator);
/**
 * Checks if the given collection contains the object using the comparator 
instead of .equals()
 */
public static E boolean contains(final CollectionE collection, final E 
object, ComparatorE comparator);
{code}
Both methods do basically the same as their native equivalient but use a 
comparator instead of equals(). 

This allows the injection of any required compare value:
{code}
final CollectionmyClass result = CollectionUtils.removeAll(base, sub, new 
ComparatormyClass() {

  public int compare(myClass o1, myClass o2) {
return o1.getB() == o2.getB();
  }
});
{code}



If you think those methods are a good idea (as proposed or changed according to 
any rules), please give me a short feedback and I'll offer an implementation as 
diff patch for review.

Cheers,

Alex



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (VFS-210) Wrapper-Mode VFS

2014-05-16 Thread Mario Ivankovits (JIRA)


[ 
https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999688#comment-13999688
 ] 

Mario Ivankovits commented on VFS-210:
--

Hi Bernd!

Sorry for my late response. Sure, you can do whatever it requires to keep the 
project running! Thanks for that!

Best regards,
Mario

 Wrapper-Mode VFS
 

 Key: VFS-210
 URL: https://issues.apache.org/jira/browse/VFS-210
 Project: Commons VFS
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits
 Fix For: 2.1


 VFS should behave more like a wrapper to the underlaying library than a full 
 blown filesystem.
 This should solve the following problems:
 * access of hidden files/directories
 * access to special folders
 * speed up FTP access



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Description: 
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!

  was:
Could you make a 3.x or 3.2.x
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!


 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (MATH-1123) NPE in BSPTree#fitToCell()

2014-05-16 Thread JIRA

Labrosse Aurélien created MATH-1123:
---

 Summary: NPE in BSPTree#fitToCell()
 Key: MATH-1123
 URL: https://issues.apache.org/jira/browse/MATH-1123
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.3
 Environment: Win32_64
Reporter: Labrosse Aurélien


Hello, 
I faced a NPE using  BSPTree#fitToCell() from the SVN trunk. I fixed the 
problem using a small patch I will attach to the ticket.




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (DBUTILS-113) Add support for conversion of ResultSet strings to enums in the BeanProcessor

2014-05-16 Thread Benedikt Ritter (JIRA)


 [ 
https://issues.apache.org/jira/browse/DBUTILS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated DBUTILS-113:


Fix Version/s: 1.6

 Add support for conversion of ResultSet strings to enums in the BeanProcessor
 -

 Key: DBUTILS-113
 URL: https://issues.apache.org/jira/browse/DBUTILS-113
 Project: Commons DbUtils
  Issue Type: Improvement
Reporter: Graylin Kim
Assignee: Benedikt Ritter
Priority: Minor
  Labels: patch
 Fix For: 1.6

 Attachments: DBUTILS-113.patch, DBUTILS-113.patch, bean_enums.diff, 
 bean_enums2.diff, bean_enums3.diff, bean_enums4.patch


 When using commons-dbutils I frequently use enum values with corresponding 
 enum in the database. In this situation, using the BeanListHandler produces 
 the following exception causing me to write a custom bean handler for enum 
 conversion.
 {quote}
 Cannot set status: incompatible types, cannot convert java.lang.String to 
 gov.nysenate.openleg.util.Storage$Status Query: SELECT * FROM changelog WHERE 
 1=1 AND time = ? AND time = ? Parameters: [2013-07-24 00:00:00, 2013-07-26 
 23:59:59]
 java.sql.SQLException: Cannot set status: incompatible types, cannot convert 
 java.lang.String to gov.nysenate.openleg.util.Storage$Status Query: SELECT * 
 FROM changelog WHERE 1=1 AND time = ? AND time = ? Parameters: [2013-07-24 
 00:00:00, 2013-07-26 23:59:59]
   at 
 org.apache.commons.dbutils.AbstractQueryRunner.rethrow(AbstractQueryRunner.java:363)
   at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:350)
   at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:288)
 {quote}
 It seems to me that commons-dbutils should be able to handle this conversion.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Description: 
Could you make a 3.x or 3.2.x
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!

  was:
Could you make a 3.x or 3.2.x
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in project, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!


 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MATH-1123) NPE in BSPTree#fitToCell()

2014-05-16 Thread JIRA


[ 
https://issues.apache.org/jira/browse/MATH-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999795#comment-13999795
 ] 

Labrosse Aurélien commented on MATH-1123:
-

Patch :
### Eclipse Workspace Patch 1.0
#P com.pollentech.maths.stats
Index: 
apacheMaths/src/main/java/org/apache/commons/math3/geometry/partitioning/BSPTree.java
===
--- 
apacheMaths/src/main/java/org/apache/commons/math3/geometry/partitioning/BSPTree.java
   (revision 1595194)
+++ 
apacheMaths/src/main/java/org/apache/commons/math3/geometry/partitioning/BSPTree.java
   (working copy)
@@ -300,6 +300,9 @@
 } else {
 s = s.split(tree.parent.cut.getHyperplane()).getMinus();
 }
+if (s == null){
+return s;
+}
 }
 return s;
 }


 NPE in BSPTree#fitToCell()
 --

 Key: MATH-1123
 URL: https://issues.apache.org/jira/browse/MATH-1123
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.3
 Environment: Win32_64
Reporter: Labrosse Aurélien

 Hello, 
 I faced a NPE using  BSPTree#fitToCell() from the SVN trunk. I fixed the 
 problem using a small patch I will attach to the ticket.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Description: 
Could you make a 3.x or 3.2.x
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in project, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!

  was:
Could you make a 3.x or 3.2.x
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in project, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.
*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!


 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in project, who run jdk8 and even compilation failures - for 
 these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Description: 
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!

  was:
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!


 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

[
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1306#comment-1306
]

Ignat Alexeyenko commented on COLLECTIONS-527:
--

[~joehni], thanks for your reply.

It's a breaking change indeed, but workaround is to publish a new major version
(e.g. 3.3.0).

Regarding making the situation even worse - why?
For people who need to migrate to JDK 8 and use collections 3.x, they need to:
# Fork the library
# Update their codebase (e.g. places, where MultiMap is implemented or
remove(Object, Object) is used).

Instead, if they do have a version which is Java 8 compatible - they need to go
with *2* and only update their codebase.

There might be other libraries that depends on commons-collections, but they
will not target compatibility with some fork. It's more realistic other
libraries will publish their compat-changes with respect to commons-collections
_only_ when original commons-collections publish a Java 8 compat changes.

Thanks!

Please create a version commons-collections 3.x for jdk 8 compatibility
---

Key: COLLECTIONS-527
URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
Project: Commons Collections
Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
Labels: java8, jdk8
Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch

Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
}
{code}
is not compatible with JDK's 8 Map
{code}
java.util.Map {
boolean remove(Object key, Object value);
}
{code}
This causes bugs in projects, who run jdk8 and even compilation failures -
for these, who implement common's MultiMap.
*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible
with Java 8. For many big project switch to commons-collections 4.x is not an
option - some transitional release version needs to be required.
Alternative would be for companies to fork commons-collections and create
their internal artifact. Why do it if the official compatibility version can
be created?
Thanks!

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Description: 
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Compilation Error*
If anyone implement MultiMap in their code, code now fails to compile:
{code}
MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap cannot 
implement remove(Object,Object) in Map
[ERROR] return type Object is not compatible with boolean
{code}

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!

  was:
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

*Compilation Error*
If anyone implement MultiMap in their code, code now fails to compile:
{code}
MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap cannot 
implement remove(Object,Object) in Map
[ERROR] return type Object is not compatible with boolean
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!


 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Compilation Error*
 If anyone implement MultiMap in their code, code now fails to compile:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (COLLECTIONS-528) Add removeAll(CollectionE collection, CollectionE remove, ComparatorE comparator) and contains(CollectionE collection, E object, ComparatorE comparator) me

2014-05-16 Thread Alexander Muthmann (JIRA)

Alexander Muthmann created COLLECTIONS-528:
--

 Summary: Add removeAll(CollectionE collection, CollectionE 
remove, ComparatorE comparator) and contains(CollectionE collection, E 
object, ComparatorE comparator) methods
 Key: COLLECTIONS-528
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-528
 Project: Commons Collections
  Issue Type: Improvement
  Components: Collection
Reporter: Alexander Muthmann


Hi,

this request originates from one of our project where we have implemented 
something similar.

The Java-Interface java.util.CollectionE specifies the two methods 
contains(Object o) and boolean removeAll(Collection? c). Both methods rely on 
the equals() method of the given Objects.

In some cases, it's not possible to change those methods and therefore 
removeAll and contains cannot be used directly. 

E.g. if you have an class myClass with property A and B and the equals method 
uses both properties, but you are only interested in property B.

To solve this problem, I'd like to propose the following extensions of 
CollectionsUtils:

{code}
/**
 * Removes all elements of remove from the collection using the comparator 
instead of .equals()
 */
public static E CollectionE removeAll(final CollectionE collection, final 
CollectionE remove, ComparatorE comparator);
/**
 * Checks if the given collection contains the object using the comparator 
instead of .equals()
 */
public static E boolean contains(final CollectionE collection, final E 
object, ComparatorE comparator);
{code}
Both methods do basically the same as their native equivalient but use a 
comparator instead of equals(). 

This allows the injection of any required compare value:
{code}
final CollectionmyClass result = CollectionUtils.removeAll(base, sub, new 
ComparatormyClass() {

  public int compare(myClass o1, myClass o2) {
return o1.getB() == o2.getB();
  }
});
{code}



If you think those methods are a good idea (as proposed or changed according to 
any rules), please give me a short feedback and I'll offer an implementation as 
diff patch for review.

Cheers,

Alex



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Description: 
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Compilation Error*
If anyone implement MultiMap in their code, compilation fails with the error:
{code}
MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap cannot 
implement remove(Object,Object) in Map
[ERROR] return type Object is not compatible with boolean
{code}

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!

  was:
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Compilation Error*
If anyone implement MultiMap in their code, code now fails to compile:
{code}
MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap cannot 
implement remove(Object,Object) in Map
[ERROR] return type Object is not compatible with boolean
{code}

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!


 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Compilation Error*
 If anyone implement MultiMap in their code, compilation fails with the error:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Attachment: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch

Attached patch, method remove in MultiMap was renamed to removeCompat, all 
implementations and tests were updated.

mvn package is green with JDK 8 (/).

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CSV-118) CSVRecord.toMap() throws NPE on formats with no headers.


 [ 
https://issues.apache.org/jira/browse/CSV-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory resolved CSV-118.
--

   Resolution: Fixed
Fix Version/s: (was: Patch Needed)
   1.0

{noformat}
commit -m action issue=CSV-118 type=fix dev=ggregory due-to=Enrique 
LaraCSVRecord.toMap() throws NPE on formats with no headers./action 
C:/vcs/svn/apache/commons/trunks-proper/csv/src/test/java/org/apache/commons/csv/CSVRecordTest.java
 
C:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVRecord.java
 C:/vcs/svn/apache/commons/trunks-proper/csv/src/changes/changes.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/changes/changes.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVRecord.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/test/java/org/apache/commons/csv/CSVRecordTest.java
Transmitting file data ...
Committed revision 1594966.
{noformat}

 CSVRecord.toMap() throws NPE on formats with no headers.
 

 Key: CSV-118
 URL: https://issues.apache.org/jira/browse/CSV-118
 Project: Commons CSV
  Issue Type: Bug
  Components: Parser
Affects Versions: 1.0
 Environment: JUNIT
Reporter: Enrique Lara
  Labels: easyfix, patch
 Fix For: 1.0

 Attachments: csv.patch

   Original Estimate: 1h
  Remaining Estimate: 1h

 The method toMap() on CSVRecord throws a NullPointerExcpetion when called on 
 records derived using a format with no headers.
 The method documentation states a null map should be returned instead.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998727#comment-13998727
 ] 

Ignat Alexeyenko edited comment on COLLECTIONS-527 at 5/15/14 3:01 PM:
---

Attached patch, method remove in MultiMap was renamed to removeCompat, all 
implementations and tests were updated. 
Patch was created based on sources of SVN repository, branch 
COLLECTIONS_3_2_BRANCH.

mvn package is green with JDK 8 (/).


was (Author: ignatalexeyenko):
Attached patch, method remove in MultiMap was renamed to removeCompat, all 
implementations and tests were updated.

mvn package is green with JDK 8 (/).

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts


[ 
https://issues.apache.org/jira/browse/VFS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998837#comment-13998837
 ] 

Gary Gregory commented on VFS-523:
--

Could you please provide a unit test with your patch?

 HdfsFileObject equals method returns true for the same path on different hosts
 --

 Key: VFS-523
 URL: https://issues.apache.org/jira/browse/VFS-523
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows 7
Reporter: Roger Whitcomb
Priority: Minor
  Labels: hdfs
 Fix For: 2.1

 Attachments: hdfsequal.diff


 If I construct two HdfsFileObject referring to the same path (for instance, 
 /) but on different hosts, the equals method will consider them equal 
 (and the hashCode method will give the same results for both) even though 
 they clearly refer to different files since they are on different hosts.
 These two methods should also factor in the HdfsFileSystem to the equation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Description: 
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

*Compilation Error*
If anyone implement MultiMap in their code, code now fails to compile:
{code}
MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap cannot 
implement remove(Object,Object) in Map
[ERROR] return type Object is not compatible with boolean
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!

  was:
Could you make a 3.x or 3.2.x release compatible with JDK8 ?
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in projects, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release version needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!


 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 *Compilation Error*
 If anyone implement MultiMap in their code, code now fails to compile:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (COLLECTIONS-528) Add removeAll(CollectionE collection, CollectionE remove, ComparatorE comparator) and contains(CollectionE collection, E object, ComparatorE comparator)

2014-05-16 Thread Thomas Neidhart (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1302#comment-1302
 ] 

Thomas Neidhart commented on COLLECTIONS-528:
-

I think it makes sense.
What do you think about using an Equator rather than a Comparator?

The call would be then like this:

{noformat}
final CollectionmyClass result = CollectionUtils.removeAll(base, sub, new 
DefaultEquatormyClass() {

  public boolean equate(myClass o1, myClass o2) {
return o1.getB() == o2.getB();
  }
});
{noformat}

 Add removeAll(CollectionE collection, CollectionE remove, ComparatorE 
 comparator) and contains(CollectionE collection, E object, ComparatorE 
 comparator) methods
 --

 Key: COLLECTIONS-528
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-528
 Project: Commons Collections
  Issue Type: Improvement
  Components: Collection
Reporter: Alexander Muthmann

 Hi,
 this request originates from one of our project where we have implemented 
 something similar.
 The Java-Interface java.util.CollectionE specifies the two methods 
 contains(Object o) and boolean removeAll(Collection? c). Both methods rely 
 on the equals() method of the given Objects.
 In some cases, it's not possible to change those methods and therefore 
 removeAll and contains cannot be used directly. 
 E.g. if you have an class myClass with property A and B and the equals method 
 uses both properties, but you are only interested in property B.
 To solve this problem, I'd like to propose the following extensions of 
 CollectionsUtils:
 {code}
 /**
  * Removes all elements of remove from the collection using the comparator 
 instead of .equals()
  */
 public static E CollectionE removeAll(final CollectionE collection, 
 final CollectionE remove, ComparatorE comparator);
 /**
  * Checks if the given collection contains the object using the comparator 
 instead of .equals()
  */
 public static E boolean contains(final CollectionE collection, final E 
 object, ComparatorE comparator);
 {code}
 Both methods do basically the same as their native equivalient but use a 
 comparator instead of equals(). 
 This allows the injection of any required compare value:
 {code}
 final CollectionmyClass result = CollectionUtils.removeAll(base, sub, new 
 ComparatormyClass() {
   public int compare(myClass o1, myClass o2) {
 return o1.getB() == o2.getB();
   }
 });
 {code}
 If you think those methods are a good idea (as proposed or changed according 
 to any rules), please give me a short feedback and I'll offer an 
 implementation as diff patch for review.
 Cheers,
 Alex



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CSV-116) Support JSON-encoded properties such as GeoJSON


[ 
https://issues.apache.org/jira/browse/CSV-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000150#comment-14000150
 ] 

Gary Gregory commented on CSV-116:
--

What happens when you use [csv] to parse such inputs?



 Support JSON-encoded properties such as GeoJSON
 ---

 Key: CSV-116
 URL: https://issues.apache.org/jira/browse/CSV-116
 Project: Commons CSV
  Issue Type: Improvement
  Components: Parser
Reporter: Ron Gavlin

 Support the three json row quoting flavors currently supported by the 
 mapnik.org csv plugin described here: 
 https://github.com/mapnik/mapnik/issues/1392.
 The proposed supported flavors are:
 {noformat}
 {\type\:\Point\,\coordinates\:[30.0,10.0]} // escaped
 '{type:Point,coordinates:[30.0,10.0]}' // single quotes no need for 
 escaped
 {type:Point,coordinates:[30.0,10.0]} // filebakery.com style
 {noformat}
 Note the following commit for this mapnik feature has sample CSV files for 
 your reference: 
 https://github.com/mapnik/mapnik/commit/f42805a5321d42f59b447a70f459058cf2c6cd5c



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (VFS-210) Wrapper-Mode VFS


 [ 
https://issues.apache.org/jira/browse/VFS-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Eckenfels updated VFS-210:


Fix Version/s: (was: 2.1)

 Wrapper-Mode VFS
 

 Key: VFS-210
 URL: https://issues.apache.org/jira/browse/VFS-210
 Project: Commons VFS
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Mario Ivankovits
Assignee: Mario Ivankovits

 VFS should behave more like a wrapper to the underlaying library than a full 
 blown filesystem.
 This should solve the following problems:
 * access of hidden files/directories
 * access to special folders
 * speed up FTP access



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

2014-05-16 Thread Joerg Schaible (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999876#comment-13999876
 ] 

Joerg Schaible commented on COLLECTIONS-527:


Ignat, I understand the problem, but it does not make sense. If we modify this 
method in the interface, commons-collections 3.x is no longer compatible with 
any previous 3.x release and can break *any* jar that depends on cc-3.x (at 
least on MultiMap) unles it is *modified* itself and rebuilt. Sorry, this 
situation would be even worse.

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (VFS-526) No Hdfs testing on Windows

Bernd Eckenfels created VFS-526:
---

 Summary: No Hdfs testing on Windows
 Key: VFS-526
 URL: https://issues.apache.org/jira/browse/VFS-526
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Win7 x64
Reporter: Bernd Eckenfels
Assignee: Bernd Eckenfels
Priority: Minor


VFS2 uses a profile hdfs to turn off the Hdfs Tests on Windows. This profile 
is quite confusingly named (as the other profiles which have a provider name 
turn on special tests and not turn them off based on OS).

Also there is no reason for this Profile (anymore?) as the HDFS Mini Cluster 
and the test cases run perfectly fine on my Windows system. The only thing 
which needs to be disabled is the execution of the umask program - but this is 
not needed on Windows it seems, anyway.

I will attach a patch, tell me what you think.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts


 [ 
https://issues.apache.org/jira/browse/VFS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Eckenfels updated VFS-523:


Attachment: hdfs-on-win.patch

Suggested patch to allow HDFS testing on Windows.

 HdfsFileObject equals method returns true for the same path on different hosts
 --

 Key: VFS-523
 URL: https://issues.apache.org/jira/browse/VFS-523
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows 7
Reporter: Roger Whitcomb
Priority: Minor
  Labels: hdfs
 Fix For: 2.1

 Attachments: hdfsequal.diff


 If I construct two HdfsFileObject referring to the same path (for instance, 
 /) but on different hosts, the equals method will consider them equal 
 (and the hashCode method will give the same results for both) even though 
 they clearly refer to different files since they are on different hosts.
 These two methods should also factor in the HdfsFileSystem to the equation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Issue Comment Deleted] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts


 [ 
https://issues.apache.org/jira/browse/VFS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Eckenfels updated VFS-523:


Comment: was deleted

(was: Suggested patch to allow HDFS testing on Windows.)

 HdfsFileObject equals method returns true for the same path on different hosts
 --

 Key: VFS-523
 URL: https://issues.apache.org/jira/browse/VFS-523
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows 7
Reporter: Roger Whitcomb
Priority: Minor
  Labels: hdfs
 Fix For: 2.1

 Attachments: hdfsequal.diff


 If I construct two HdfsFileObject referring to the same path (for instance, 
 /) but on different hosts, the equals method will consider them equal 
 (and the hashCode method will give the same results for both) even though 
 they clearly refer to different files since they are on different hosts.
 These two methods should also factor in the HdfsFileSystem to the equation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MATH-418) add a storeless version of Percentile

2014-05-16 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999720#comment-13999720
 ] 

Gilles commented on MATH-418:
-

Thanks for you effort up to now. There are however some remarks about the 
coding style, to try and ensure consistency throughout the Commons Math 
codebase:

* You should not use an underscore as a suffix or prefix (for method or 
variable names)
* For constants, use the final keyword in the declaration
* Do not overuse p in comments (especially in protected and private classes)
* No initial uppercase letter after @return
* Do not use protected fields (i.e. create setters instead)
* Conform to the natural rules for capitalization in comments (e.g. no 
uppercase for the second word in a sentence)
* Remove code that was commented-out (and indicated as unnecessary)
* Do not start a @param or @throws with the word is (or passed in)
* Do not use a single uppercase letter as a variable name
* Prefer (moderately) long names for instance fields and methods wherever it 
would make the code more self-documenting (cf. ns, nps, qs)
* Avoid consecutive uppercase letters (e.g. processADataPoint should rather 
be  processDataPoint).
* (Personal preference) The first line of a Javadoc comment should not be 
broken after @param x; it is harder to read and needlessly increases the 
height of the text.
* Indicates the purpose of package visibility when it is used instead of 
private or protected.
* Fully comment public fields, parameters, constructor and methods: see e.g. 
the constructor of Marker where the reader is referred to the documentation 
of a _private_ field (which would not appear in the generated HTML)

I can't comment much about the algorithmic side.
A few points I noticed:
# The input (quantile) is allowed to be either in \[0, 1\] or in (1, 100]; this 
is error-prone and this kind of flexibility is not to be handled at the math 
level (IMHO). The input should be a primitive double, not a Number.
# At line 1206, the error message is abused, as it should refer to an index.
# At line 1211, use NullArgumentException in place of 
MathIllegalArgumentException.
# At line 1214, do not combine different types of failures, and use 
DimensionMismatchException in place of MathIllegalArgumentException.


 add a storeless version of Percentile
 -

 Key: MATH-418
 URL: https://issues.apache.org/jira/browse/MATH-418
 Project: Commons Math
  Issue Type: New Feature
Affects Versions: 2.1
Reporter: Luc Maisonobe
 Fix For: 4.0

 Attachments: psquare-patch


 The Percentile class can handle only in-memory data.
 It would be interesting to use an on-line algorithm to estimate quantiles as 
 a storeless statistic.
 An example of such an algorithm is the exponentially weighted stochastic 
 approximation  described in a 2000 paper by Fei Chen ,  Diane Lambert  and 
 José C. Pinheiro Incremental Quantile Estimation for Massive Tracking which 
 can be retrieved from CiteSeerX at 
 [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.1580].



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts


[ 
https://issues.apache.org/jira/browse/VFS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000273#comment-14000273
 ] 

Bernd Eckenfels edited comment on VFS-523 at 5/16/14 8:51 PM:
--

BTW: there is also a test which tests if equal works for the positive case. I 
guess the negative case would be a bit more complicated if you actually want to 
test a second hdfs instance.

Anyway, this change here make the test a bit more complete:
{code}
public void testEquals() throws Exception
{
// Create test file (and check parent was created)
final FileObject dir = manager.resolveFile(TEST_DIR1);
Assert.assertNotNull(dir);
Assert.assertFalse(dir.exists());
final FileObject file1 = createTestFile(hdfs);
Assert.assertTrue(file1.exists());
Assert.assertTrue(dir.exists());

// Get a handle to the same file and ensure it is equal
final FileObject file2 = manager.resolveFile(TEST_FILE1);
Assert.assertEquals(file1, file2);

// Ensure different files on same filesystem are not equal
Assert.assertNotEquals(dir, file1);
Assert.assertNotEquals(dir, file2);
}
{code}


was (Author: b.eckenfels):
BTW: there is also a test which tests if equal works for the positive case. I 
guess the negative case would be a bit more complicated if you actually want to 
test a second hdfs instance.

Anyway, this change here make the test a bit more complete:
{code}
public void testEquals() throws Exception
{
final FileObject dir = manager.resolveFile(TEST_DIR1);
Assert.assertNotNull(dir);
Assert.assertFalse(dir.exists());

// Create the test file
final FileObject file1 = createTestFile(hdfs);
Assert.assertTrue(file1.exists());
Assert.assertTrue(dir.exists());

// Get a handle to the same file and ensure its equal
final FileObject file2 = manager.resolveFile(TEST_FILE1);
Assert.assertEquals(file1, file2);

// Ensure different files on same filesystem are not equal
Assert.assertNotEquals(dir, file1);
Assert.assertNotEquals(dir, file2);
}
{code}

 HdfsFileObject equals method returns true for the same path on different hosts
 --

 Key: VFS-523
 URL: https://issues.apache.org/jira/browse/VFS-523
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows 7
Reporter: Roger Whitcomb
Priority: Minor
  Labels: hdfs
 Fix For: 2.1

 Attachments: hdfsequal.diff


 If I construct two HdfsFileObject referring to the same path (for instance, 
 /) but on different hosts, the equals method will consider them equal 
 (and the hashCode method will give the same results for both) even though 
 they clearly refer to different files since they are on different hosts.
 These two methods should also factor in the HdfsFileSystem to the equation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (VFS-526) No Hdfs testing on Windows


 [ 
https://issues.apache.org/jira/browse/VFS-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Eckenfels updated VFS-526:


Attachment: hdfs-on-win.patch

Suggested patch to enable Hdfs testing on Windows

 No Hdfs testing on Windows
 --

 Key: VFS-526
 URL: https://issues.apache.org/jira/browse/VFS-526
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Win7 x64
Reporter: Bernd Eckenfels
Assignee: Bernd Eckenfels
Priority: Minor
  Labels: hdfs, testing, windows
 Fix For: 2.1

 Attachments: hdfs-on-win.patch


 VFS2 uses a profile hdfs to turn off the Hdfs Tests on Windows. This 
 profile is quite confusingly named (as the other profiles which have a 
 provider name turn on special tests and not turn them off based on OS).
 Also there is no reason for this Profile (anymore?) as the HDFS Mini Cluster 
 and the test cases run perfectly fine on my Windows system. The only thing 
 which needs to be disabled is the execution of the umask program - but this 
 is not needed on Windows it seems, anyway.
 I will attach a patch, tell me what you think.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

Ignat Alexeyenko created COLLECTIONS-527:


 Summary: Please create a version commons-collections 3.x for jdk 8 
compatibility
 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch

Could you make a 3.x or 3.2.x
{code}
org.apache.commons.collections.MultiHashMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (MATH-1122) Interpolation with extrapolation handling

2014-05-16 Thread JIRA

Mikael Öhman created MATH-1122:
--

 Summary: Interpolation with extrapolation handling
 Key: MATH-1122
 URL: https://issues.apache.org/jira/browse/MATH-1122
 Project: Commons Math
  Issue Type: Wish
Affects Versions: 3.3
Reporter: Mikael Öhman
Priority: Minor


Hello.

We use commons math and are happy with it. Great work.

In the case of interpolators, a common requirement for us is to have 
extrapolation policies. For example, we may have cubic spline interpolation on 
the curve and for any points outside the curve we may wish to linearly 
extrapolate or we may wish to cap the value at the extreme point.

Is this a feature you would consider adding or is there an existing/easy 
workaround available.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts


 [ 
https://issues.apache.org/jira/browse/VFS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Eckenfels updated VFS-523:


Attachment: (was: hdfs-on-win.patch)

 HdfsFileObject equals method returns true for the same path on different hosts
 --

 Key: VFS-523
 URL: https://issues.apache.org/jira/browse/VFS-523
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows 7
Reporter: Roger Whitcomb
Priority: Minor
  Labels: hdfs
 Fix For: 2.1

 Attachments: hdfsequal.diff


 If I construct two HdfsFileObject referring to the same path (for instance, 
 /) but on different hosts, the equals method will consider them equal 
 (and the hashCode method will give the same results for both) even though 
 they clearly refer to different files since they are on different hosts.
 These two methods should also factor in the HdfsFileSystem to the equation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CSV-116) Support JSON-encoded properties such as GeoJSON


[ 
https://issues.apache.org/jira/browse/CSV-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998982#comment-13998982
 ] 

Gary Gregory commented on CSV-116:
--

What is row quoting BTW? What is the pointing of putting the whole row in 
quotes?

 Support JSON-encoded properties such as GeoJSON
 ---

 Key: CSV-116
 URL: https://issues.apache.org/jira/browse/CSV-116
 Project: Commons CSV
  Issue Type: Improvement
  Components: Parser
Reporter: Ron Gavlin

 Support the three json row quoting flavors currently supported by the 
 mapnik.org csv plugin described here: 
 https://github.com/mapnik/mapnik/issues/1392.
 The proposed supported flavors are:
 {noformat}
 {\type\:\Point\,\coordinates\:[30.0,10.0]} // escaped
 '{type:Point,coordinates:[30.0,10.0]}' // single quotes no need for 
 escaped
 {type:Point,coordinates:[30.0,10.0]} // filebakery.com style
 {noformat}
 Note the following commit for this mapnik feature has sample CSV files for 
 your reference: 
 https://github.com/mapnik/mapnik/commit/f42805a5321d42f59b447a70f459058cf2c6cd5c



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000368#comment-14000368
 ] 

Ignat Alexeyenko commented on COLLECTIONS-527:
--

In Maven world one probably gets something like:
{code}
Project
   `-- dependency A
  `-- commons-collection-3.2.1
   `--dependency B
  `--commons-collections-3.3.0
{code}
Where Maven resolves version of 3.3.0 and if *dependency A* uses some of 
commons-collection's remove(Object, Object) values they must receive runtime 
exceptions. This situation can be solved either by:
* using patched version of dependency A, that is compatible with 
commons-collections 3.3.0
* loading dependencies in different class loaders

Consider the other case, there's only commons-collection 3.2.1 in project:
{code}
Project
   `-- dependency A
  `-- commons-collection-3.2.1
   `--dependency B
  `--commons-collections-3.2.1
{code}
The same *dependency A* still uses some of commons-collection's remove(Object, 
Object) and we run Java 8. Again, they must receive same runtime exceptions - 
even without single change in commons-collection 3.2.1.

*Adopting Java 8*
So projects are already doomed if they need to run Java 8 with 
commons-collections 3.2.1. Transition to commons-collections4 might not be an 
option, as there are too much code changes required in projects. Even more code 
changes in other libraries (like *dependency A*)!

*More options*
Finally, developers aren't forced to upgrade to commons-collections 3.3. 
Developers may be happy with older Java or they're fortunate to avoid 
exceptions in remove(Object, Object) invocations on MultiMaps.

In any case, having a new compatibility release leaves more options for other 
projects and developers to react, then having no compatibility release at all. 
As mentioned earlier, this must have a coherent impact on other libraries (like 
*dependency A*) - much better then just a custom project fork.

Thanks [~joehni] for your time.

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Compilation Error*
 If anyone implement MultiMap in their code, compilation fails with the error:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MATH-1120) Need Percentile computations that can be matched with standard spreadsheet formula

2014-05-16 Thread Gilles (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13999729#comment-13999729
 ] 

Gilles commented on MATH-1120:
--

bq [...] new {{ExcelPercentile}} class [...]

That looks out of place in a free project. ;)

Couldn't the conversion from one definition to another be handled before 
passing the value to the CM class?


 Need Percentile computations that can be matched with standard spreadsheet 
 formula
 --

 Key: MATH-1120
 URL: https://issues.apache.org/jira/browse/MATH-1120
 Project: Commons Math
  Issue Type: Improvement
Affects Versions: 3.2
Reporter: Venkatesha Murthy TS
  Labels: Percentile
 Fix For: 4.0

   Original Estimate: 504h
  Remaining Estimate: 504h

 The current Percentile implementation assumes and hard-codes the quantile pth 
 position as 
 p * (N+1)/100 and provides a kth selected value.
 However if we need to verify compare/contrast with standard statistical tools 
 such as say MS Excel; it would be good to provide an extensible way of 
 morphing this selection of position than hard code.
 For example in order to generate the percentile closely matching with MS 
 Excel the position required may be [p*(N-1)/100]+1.
 I do have patch ready with small change needed in Percentile class and a new 
 ExcelPercentile class written with tests closely matching with that of 
 PercentileTest class.
 Please let me know if i could submit this as a patch.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (VFS-142) Clear ThreadData after all streams are closed, fixes a memory leak


[ 
https://issues.apache.org/jira/browse/VFS-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998741#comment-13998741
 ] 

Gary Gregory commented on VFS-142:
--

This is all quite alarming. 

Which behavior can be attributed to the 2.0 and trunk version of the code?

 Clear ThreadData after all streams are closed, fixes a memory leak
 --

 Key: VFS-142
 URL: https://issues.apache.org/jira/browse/VFS-142
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 1.1
Reporter: Adam Heath
 Attachments: fix_ThreadData-clear.patch


 After all streams are closed in FileContentThreadData, clear the ThreadLocal.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (DBUTILS-113) Add support for conversion of ResultSet strings to enums in the BeanProcessor

2014-05-16 Thread Benedikt Ritter (JIRA)


 [ 
https://issues.apache.org/jira/browse/DBUTILS-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved DBUTILS-113.
-

Resolution: Fixed

{code}
bene@localhost:~/workspace/apache/commons/dbutils$ svn ci -m DBUTILS-113: Add 
support for conversion of ResultSet strings to enums in the BeanProcessor. 
Thanks to Graylin Kim and Michael Osipov.
Sendingsrc/changes/changes.xml
Sendingsrc/main/java/org/apache/commons/dbutils/BeanProcessor.java
Sendingsrc/test/java/org/apache/commons/dbutils/BaseTestCase.java
Sending
src/test/java/org/apache/commons/dbutils/BasicRowProcessorTest.java
Sendingsrc/test/java/org/apache/commons/dbutils/BeanProcessorTest.java
Sending
src/test/java/org/apache/commons/dbutils/ResultSetIteratorTest.java
Sendingsrc/test/java/org/apache/commons/dbutils/TestBean.java
Sending
src/test/java/org/apache/commons/dbutils/handlers/ArrayHandlerTest.java
Sending
src/test/java/org/apache/commons/dbutils/handlers/ArrayListHandlerTest.java
Sending
src/test/java/org/apache/commons/dbutils/handlers/BeanHandlerTest.java
Sending
src/test/java/org/apache/commons/dbutils/handlers/BeanListHandlerTest.java
Sending
src/test/java/org/apache/commons/dbutils/handlers/KeyedHandlerTest.java
Sending
src/test/java/org/apache/commons/dbutils/handlers/MapHandlerTest.java
Sending
src/test/java/org/apache/commons/dbutils/handlers/MapListHandlerTest.java
Transmitting file data ..
Committed revision 1593217.
{code}

Thanks for contributing (and sorry for the delay)

 Add support for conversion of ResultSet strings to enums in the BeanProcessor
 -

 Key: DBUTILS-113
 URL: https://issues.apache.org/jira/browse/DBUTILS-113
 Project: Commons DbUtils
  Issue Type: Improvement
Reporter: Graylin Kim
Assignee: Benedikt Ritter
Priority: Minor
  Labels: patch
 Fix For: 1.6

 Attachments: DBUTILS-113.patch, DBUTILS-113.patch, bean_enums.diff, 
 bean_enums2.diff, bean_enums3.diff, bean_enums4.patch


 When using commons-dbutils I frequently use enum values with corresponding 
 enum in the database. In this situation, using the BeanListHandler produces 
 the following exception causing me to write a custom bean handler for enum 
 conversion.
 {quote}
 Cannot set status: incompatible types, cannot convert java.lang.String to 
 gov.nysenate.openleg.util.Storage$Status Query: SELECT * FROM changelog WHERE 
 1=1 AND time = ? AND time = ? Parameters: [2013-07-24 00:00:00, 2013-07-26 
 23:59:59]
 java.sql.SQLException: Cannot set status: incompatible types, cannot convert 
 java.lang.String to gov.nysenate.openleg.util.Storage$Status Query: SELECT * 
 FROM changelog WHERE 1=1 AND time = ? AND time = ? Parameters: [2013-07-24 
 00:00:00, 2013-07-26 23:59:59]
   at 
 org.apache.commons.dbutils.AbstractQueryRunner.rethrow(AbstractQueryRunner.java:363)
   at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:350)
   at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:288)
 {quote}
 It seems to me that commons-dbutils should be able to handle this conversion.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ignat Alexeyenko updated COLLECTIONS-527:
-

Description: 
Could you make a 3.x or 3.2.x
{code}
org.apache.commons.collections.MultiMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

This causes bugs in project, who run jdk8 and even compilation failures - for 
these, who implement common's MultiMap.
*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!

  was:
Could you make a 3.x or 3.2.x
{code}
org.apache.commons.collections.MultiHashMap {
   public Object remove(Object key, Object item);
}
{code}

is not compatible with JDK's 8 Map

{code}
java.util.Map {
   boolean remove(Object key, Object value);
}
{code}

*Reasoning*
JDK 8 is here and being adopted. collection-commons are not yet compatible with 
Java 8. For many big project switch to commons-collections 4.x is not an option 
- some transitional release needs to be required.

Alternative would be for companies to fork commons-collections and create their 
internal artifact. Why do it if the official compatibility version can be 
created?

Thanks!


 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in project, who run jdk8 and even compilation failures - for 
 these, who implement common's MultiMap.
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CSV-116) Support JSON-encoded properties such as GeoJSON

2014-05-16 Thread Sebb (JIRA)


[ 
https://issues.apache.org/jira/browse/CSV-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998745#comment-13998745
 ] 

Sebb commented on CSV-116:
--

Not sure this belongs in the CSV component.

 Support JSON-encoded properties such as GeoJSON
 ---

 Key: CSV-116
 URL: https://issues.apache.org/jira/browse/CSV-116
 Project: Commons CSV
  Issue Type: Improvement
  Components: Parser
Reporter: Ron Gavlin

 Support the three json row quoting flavors currently supported by the 
 mapnik.org csv plugin described here: 
 https://github.com/mapnik/mapnik/issues/1392.
 The proposed supported flavors are:
 {noformat}
 {\type\:\Point\,\coordinates\:[30.0,10.0]} // escaped
 '{type:Point,coordinates:[30.0,10.0]}' // single quotes no need for 
 escaped
 {type:Point,coordinates:[30.0,10.0]} // filebakery.com style
 {noformat}
 Note the following commit for this mapnik feature has sample CSV files for 
 your reference: 
 https://github.com/mapnik/mapnik/commit/f42805a5321d42f59b447a70f459058cf2c6cd5c



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts


[ 
https://issues.apache.org/jira/browse/VFS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000470#comment-14000470
 ] 

Bernd Eckenfels commented on VFS-523:
-

the `equals` uses `path.equals()` but the `hashcode()` uses 
`path.getName().toString().hashCode()` (even before the patch). Do we want to 
unify this as well?

BTW: I would merge the patch, I have verified that I can actually test Hdfs 
(and I can on Windows, see VFS-526)

 HdfsFileObject equals method returns true for the same path on different hosts
 --

 Key: VFS-523
 URL: https://issues.apache.org/jira/browse/VFS-523
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows 7
Reporter: Roger Whitcomb
Priority: Minor
  Labels: hdfs
 Fix For: 2.1

 Attachments: hdfsequal.diff


 If I construct two HdfsFileObject referring to the same path (for instance, 
 /) but on different hosts, the equals method will consider them equal 
 (and the hashCode method will give the same results for both) even though 
 they clearly refer to different files since they are on different hosts.
 These two methods should also factor in the HdfsFileSystem to the equation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

2014-05-16 Thread Thomas Neidhart (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000469#comment-14000469
 ] 

Thomas Neidhart edited comment on COLLECTIONS-527 at 5/16/14 11:09 PM:
---

We could release a commons-collections 3.x version with different maven 
coordinates and package name for java 8 compatibility.
But in any case, projects would have to adopt and I doubt that there are so 
many changes required to upgrade to collections 4 as claimed.

Edit: a drop-in replacement as requested by the OP is simply impossible as sebb 
and Joerg have pointed out.


was (Author: tn):
We could release a commons-collections 3.x version with different maven 
coordinates and package name for java 8 compatibility.
But in any case, projects would have to adopt and I doubt that there are so 
many changes required to upgrade to collections 4 as claimed.

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Compilation Error*
 If anyone implement MultiMap in their code, compilation fails with the error:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

2014-05-16 Thread Sebb (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000452#comment-14000452
 ] 

Sebb commented on COLLECTIONS-527:
--

If any dependency actually uses the current remove() method, removing it will 
break the application.
As this is a public method we cannot be sure that it is not being used 
anywhere, so dropping the method is not an option if we are to retain binary 
compatibility.
It's not possible to have two different versions of the same class in the same 
class-loader, which is why API breaks need a new package name (and new Maven 
coordinates).

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Compilation Error*
 If anyone implement MultiMap in their code, compilation fails with the error:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

2014-05-16 Thread Sebb (JIRA)


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebb resolved COLLECTIONS-527.
--

Resolution: Won't Fix

It's not possible to fix this

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Compilation Error*
 If anyone implement MultiMap in their code, compilation fails with the error:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

2014-05-16 Thread Thomas Neidhart (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000469#comment-14000469
 ] 

Thomas Neidhart commented on COLLECTIONS-527:
-

We could release a commons-collections 3.x version with different maven 
coordinates and package name for java 8 compatibility.
But in any case, projects would have to adopt and I doubt that there are so 
many changes required to upgrade to collections 4 as claimed.

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Compilation Error*
 If anyone implement MultiMap in their code, compilation fails with the error:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (LANG-1015) Adding the new JsonToStringStyle to ToStringStyle

2014-05-16 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000566#comment-14000566
 ] 

ASF GitHub Bot commented on LANG-1015:
--

GitHub user thiagoh opened a pull request:

https://github.com/apache/commons-lang/pull/26

Adding the new JsonToStringStyle to ToStringStyle

Implementation of `JsonToStringStyle` inside `ToStringStyle` that outputs 
the String representation of the object in json format.

Jira ticket https://issues.apache.org/jira/browse/LANG-1015

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/thiagoh/commons-lang branch-3-json-style

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/26.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #26


commit 609775c1acfae2da487fb762337a7d4d9c44cef5
Author: thiagoh thia...@gmail.com
Date:   2014-05-16T17:07:08Z

json to string style

commit 2dd9ee994beb9a45001c94835443092dc3962d7c
Author: thiagoh thia...@gmail.com
Date:   2014-05-17T00:32:26Z

implementation of JsonToStringStyle with test cases




 Adding the new JsonToStringStyle to ToStringStyle
 -

 Key: LANG-1015
 URL: https://issues.apache.org/jira/browse/LANG-1015
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.*, lang.builder.*
Affects Versions: 4.0
Reporter: Thiago Andrade
Assignee: Benedikt Ritter
  Labels: github

 Placeholder ticket for github PR 25: 
 https://github.com/apache/commons-lang/pull/26



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (LANG-1015) Adding the new JsonToStringStyle to ToStringStyle


 [ 
https://issues.apache.org/jira/browse/LANG-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thiago Andrade updated LANG-1015:
-

Description: Placeholder ticket for github PR 26: 
https://github.com/apache/commons-lang/pull/26  (was: Placeholder ticket for 
github PR 25: https://github.com/apache/commons-lang/pull/26)

 Adding the new JsonToStringStyle to ToStringStyle
 -

 Key: LANG-1015
 URL: https://issues.apache.org/jira/browse/LANG-1015
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.*, lang.builder.*
Affects Versions: 4.0
Reporter: Thiago Andrade
Assignee: Benedikt Ritter
  Labels: github

 Placeholder ticket for github PR 26: 
 https://github.com/apache/commons-lang/pull/26



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (LANG-1015) Adding the new JsonToStringStyle to ToStringStyle

Thiago Andrade created LANG-1015:


 Summary: Adding the new JsonToStringStyle to ToStringStyle
 Key: LANG-1015
 URL: https://issues.apache.org/jira/browse/LANG-1015
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.*
Affects Versions: 4.0
Reporter: Thiago Andrade
Assignee: Benedikt Ritter


Placeholder ticket for github PR 25: 
https://github.com/apache/commons-lang/pull/25



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (COLLECTIONS-527) Please create a version commons-collections 3.x for jdk 8 compatibility

2014-05-16 Thread Joerg Schaible (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000526#comment-14000526
 ] 

Joerg Schaible commented on COLLECTIONS-527:


And let's come back to the facts. cc-3 *runs* on Java 8, you simply cannot 
compile with it (or against its runtime). And since anything that uses 
MultiMap.remove must have been compiled with an earlier runtime too, binary 
runtime compatibility stays fine.

Only people are affected that try to compile with Java 8 against cc-3. However, 
since they will have to adjust their source code, they can do directly the 
proper way. Most of the stuff will simply compile by replacing the import 
statements with the new package of cc-4 (actually for minimal changes it is 
enough to upgrade the code using MultiMap and depend on both cc versions). And 
if the source has been upgraded, the dependencies that still use cc-3 are 
completely happy and the new code running with cc-4 is also. And we, too, since 
we did not introduce an incompatible version into the cc-3.x namespace.

I know very well that that some Linux distros try to use that patch (actually I 
am using Gentoo for more than a decade), because they tend to build anything on 
their own, but if they insist on creating a version hell with their distro, 
they may do so - unless they do not blame us later on for incompatibilities.

 Please create a version commons-collections 3.x for jdk 8 compatibility
 ---

 Key: COLLECTIONS-527
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-527
 Project: Commons Collections
  Issue Type: Bug
Reporter: Ignat Alexeyenko
Priority: Blocker
  Labels: java8, jdk8
 Attachments: COLLECTIONS_3_2_BRANCH_COLLECTIONS_527.patch


 Could you make a 3.x or 3.2.x release compatible with JDK8 ?
 {code}
 org.apache.commons.collections.MultiMap {
public Object remove(Object key, Object item);
 }
 {code}
 is not compatible with JDK's 8 Map
 {code}
 java.util.Map {
boolean remove(Object key, Object value);
 }
 {code}
 This causes bugs in projects, who run jdk8 and even compilation failures - 
 for these, who implement common's MultiMap.
 *Compilation Error*
 If anyone implement MultiMap in their code, compilation fails with the error:
 {code}
 MyMultiHashMap.java:[11,7] error: remove(Object,Object) in MultiHashMap 
 cannot implement remove(Object,Object) in Map
 [ERROR] return type Object is not compatible with boolean
 {code}
 *Reasoning*
 JDK 8 is here and being adopted. collection-commons are not yet compatible 
 with Java 8. For many big project switch to commons-collections 4.x is not an 
 option - some transitional release version needs to be required.
 Alternative would be for companies to fork commons-collections and create 
 their internal artifact. Why do it if the official compatibility version can 
 be created?
 Thanks!



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts


[ 
https://issues.apache.org/jira/browse/VFS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000273#comment-14000273
 ] 

Bernd Eckenfels commented on VFS-523:
-

BTW: there is also a test which tests if equal works for the positive case. I 
guess the negative case would be a bit more complicated if you actually want to 
test a second hdfs instance.

Anyway, this change here make the test a bit more complete:
{code}
public void testEquals() throws Exception
{
final FileObject dir = manager.resolveFile(TEST_DIR1);
Assert.assertNotNull(dir);
Assert.assertFalse(dir.exists());

// Create the test file
final FileObject file1 = createTestFile(hdfs);
Assert.assertTrue(file1.exists());
Assert.assertTrue(dir.exists());

// Get a handle to the same file and ensure its equal
final FileObject file2 = manager.resolveFile(TEST_FILE1);
Assert.assertEquals(file1, file2);

// Ensure different files on same filesystem are not equal
Assert.assertNotEquals(dir, file1);
Assert.assertNotEquals(dir, file2);
}
{code}

 HdfsFileObject equals method returns true for the same path on different hosts
 --

 Key: VFS-523
 URL: https://issues.apache.org/jira/browse/VFS-523
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows 7
Reporter: Roger Whitcomb
Priority: Minor
  Labels: hdfs
 Fix For: 2.1

 Attachments: hdfsequal.diff


 If I construct two HdfsFileObject referring to the same path (for instance, 
 /) but on different hosts, the equals method will consider them equal 
 (and the hashCode method will give the same results for both) even though 
 they clearly refer to different files since they are on different hosts.
 These two methods should also factor in the HdfsFileSystem to the equation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (LANG-1015) Adding the new JsonToStringStyle to ToStringStyle


 [ 
https://issues.apache.org/jira/browse/LANG-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thiago Andrade updated LANG-1015:
-

Description: Placeholder ticket for github PR 25: 
https://github.com/apache/commons-lang/pull/26  (was: Placeholder ticket for 
github PR 25: https://github.com/apache/commons-lang/pull/25)

 Adding the new JsonToStringStyle to ToStringStyle
 -

 Key: LANG-1015
 URL: https://issues.apache.org/jira/browse/LANG-1015
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.*
Affects Versions: 4.0
Reporter: Thiago Andrade
Assignee: Benedikt Ritter
  Labels: github

 Placeholder ticket for github PR 25: 
 https://github.com/apache/commons-lang/pull/26



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts


[ 
https://issues.apache.org/jira/browse/VFS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14000582#comment-14000582
 ] 

Bernd Eckenfels commented on VFS-523:
-

I just checked the other FileObject implementations, none of them overwrites 
the basic equals/hashcode implementation. I wonder if a (better/other) solution 
would be to remove the implementations?

Using same object compare and system hashcode would work in most situations 
where the caching is used.

If we think this is not enough, then maybe it would be better to add 
hashcode+equals to the AbstractFileObject where it would compare the fileName 
and the filesystem (instance).

 HdfsFileObject equals method returns true for the same path on different hosts
 --

 Key: VFS-523
 URL: https://issues.apache.org/jira/browse/VFS-523
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.1
 Environment: Windows 7
Reporter: Roger Whitcomb
Priority: Minor
  Labels: hdfs
 Fix For: 2.1

 Attachments: hdfsequal.diff


 If I construct two HdfsFileObject referring to the same path (for instance, 
 /) but on different hosts, the equals method will consider them equal 
 (and the hashCode method will give the same results for both) even though 
 they clearly refer to different files since they are on different hosts.
 These two methods should also factor in the HdfsFileSystem to the equation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (VFS-217) Preserve the last modified time when copying with j-cifs (smb://)


 [ 
https://issues.apache.org/jira/browse/VFS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Eckenfels resolved VFS-217.
-

Resolution: Cannot Reproduce

In VFS2 I see SET_LAST_MODIFIED_FILE and _DIR is present and the implementation 
uses SmbFile.setLastModified(). So I guess it has been implemnted meanwhile. 
Please reopen if you disagree.

 Preserve the last modified time when copying with j-cifs (smb://)
 -

 Key: VFS-217
 URL: https://issues.apache.org/jira/browse/VFS-217
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 1.0
Reporter: Alex C

 Hi,
 Please can you add support for preserving the last modified time when copying 
 files with j-cifs (smb://). I can see from this wiki page that it is 
 currently not supported for smb ('setLastModifiedFile' capability):
 http://wiki.apache.org/commons/VfsCapabilitiesMatrix



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (LANG-1015) Adding the new JsonToStringStyle to ToStringStyle


 [ 
https://issues.apache.org/jira/browse/LANG-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thiago Andrade updated LANG-1015:
-

Component/s: lang.builder.*

 Adding the new JsonToStringStyle to ToStringStyle
 -

 Key: LANG-1015
 URL: https://issues.apache.org/jira/browse/LANG-1015
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.*, lang.builder.*
Affects Versions: 4.0
Reporter: Thiago Andrade
Assignee: Benedikt Ritter
  Labels: github

 Placeholder ticket for github PR 25: 
 https://github.com/apache/commons-lang/pull/26



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (VFS-308) getLastModifiedTime() returns 0 in the case of Danish Locale


 [ 
https://issues.apache.org/jira/browse/VFS-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Eckenfels resolved VFS-308.
-

Resolution: Cannot Reproduce

Your testcase is not using VFS lastModified but normal Java File API. Also it 
looks like it will return 0 when you turn debugging on. I can also see no local 
specific code in getting the lastModified time on the LocalFileSystem, 
therefore I close this bug. Please feel free to reopen it, if you have more 
details about this problem.

 getLastModifiedTime() returns 0 in the case of Danish Locale
 

 Key: VFS-308
 URL: https://issues.apache.org/jira/browse/VFS-308
 Project: Commons VFS
  Issue Type: Bug
 Environment: OS:Solaris
 Locale:Danish
 Common-VFS-patch 3
Reporter: Manju
Priority: Minor
  Labels: Danish, Locale
 Attachments: VfsTest.java


 When we try to create a file and access its lastModifiedTime for US locale 
 returns correct long value.
 But in the case of Danish Locale it returns always 0 for the month of May.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (VFS-523) HdfsFileObject equals method returns true for the same path on different hosts