./modules/system/layers/base/org/apache/commons/beanutils/main/commons-beanutils-1.8.3-redhat-2.jar ./modules/system/layers/base/org/apache/commons/collections/main/commons-collections-3.2.1-redhat-2.jar org.apache.commons.collections.ArrayStack org.apache.commons.collections.Buffer org.apache.commons.collections.BufferUnderflowException org.apache.commons.collections.FastHashMap org.apache.commons.collections.FastHashMap$1 org.apache.commons.collections.FastHashMap$CollectionView org.apache.commons.collections.FastHashMap$CollectionView$CollectionViewIterator org.apache.commons.collections.FastHashMap$EntrySet org.apache.commons.collections.FastHashMap$KeySet org.apache.commons.collections.FastHashMap$Values
Paul, can you check it or is it item for Fernando?
Looks like this issue also happened in 6.0 (bug 899789). Assigning to dwalluck since he normally builds commons-beanutils.
Commons-Collections ------------------- BeanUtils now ships with a small number of commons collections classes. This is a temporary measure intended to allow BeanUtils core to be used with either commons-collections 2 or commons-collections-3 without a dependency on either. It is intended that soon BeanUtils core will have no dependency on any commons collection packaged classes. Files ----- src/main/java/org/apache/commons/collections/Buffer.java src/main/java/org/apache/commons/collections/ArrayStack.java src/main/java/org/apache/commons/collections/BufferUnderflowException.java src/main/java/org/apache/commons/collections/FastHashMap.java src/main/java/org/apache/commons/collections/package.html But the pom already has an optional dependency on commons-collections.
Note that there's already a jar split between commons-beanutils-bean-collections and commons-beanutils-core. Here's how it is upstream: (1) commons-beanutils: commons-collections, optional (2) commons-beanutils-bean-collections: commons-collections, optional (3) commons-beanutils-core: commons-collections, none Now, I think (1) and (3) are correct for us. The problem is with (2), I think commons-collections should be made non-optional. Except I don't think we ship with jar anyway. Do we really need commons-beanutils or should we be using commons-beanutils-core? If we only need commons-beanutils-core, then I don't think we need to depend on commons-collections for this dep at all.
I will file an issue to try to get this fixed upstream by changing from commons-beanutils to commons-beanutils-core.
Created <https://issues.jboss.org/browse/WFLY-1749>.
State in EAP 6.1.1 ER7 is the same as Rosta wrote in Description -- the same duplicated classes. The only change is that now there is commons-beanutils-1.8.3.redhat-3.jar instead of commons-beanutils-1.8.3-redhat-2.jar.
(In reply to Nikoleta Ziakova from comment #8) > State in EAP 6.1.1 ER7 is the same as Rosta wrote in Description -- the same > duplicated classes. The only change is that now there is > commons-beanutils-1.8.3.redhat-3.jar instead of > commons-beanutils-1.8.3-redhat-2.jar. This is expected. The status is not expected to change until <https://issues.jboss.org/browse/WFLY-1749> is handled upstream. But, I don't believe that there's a way to depend on an external bug. In fact, we currently do not intend to remove the classes, but to switch the dependency from commons-beanutils, which has the classes, to commons-beanutils-core, which does not have the classes. One reason for doing this is that we wanted to reduce the changes here between the product an upstream. I basically agree with this as a goal, except per my comment #4, it looks as if the Maven dependency flags for the commons-collections dependency may be somewhat wrong upstream.
I believe it was fixed in the version linked, but pgier didn't see the need to apply the fix in later builds. According to him, I don't think it is necessary, but it's probably best to ask him.
Closing won't fix. The issue is resolved upstream. As the common beanutils and collections modules are marked private, the user should not depend on them directly. Put the version of the jars wanted into the custom module or in another custom module to avoid using the private jboss module and to resolve the issue.