Hi, please watch out - there is a security issue mentioned at heise.de (zero day exploid) which affects common collections:
org/apache/commons/collections/functors/InvokerTransformer.class Here is an article in english which mentions that issue: http://www.infoq.com/news/2015/11/commons-exploit kind regards Tobias > Am 10.11.2015 um 22:37 schrieb Martin Grigorov <[email protected]>: > > +1 to keep the dependency > > I've also took a look at the code and it seems we will need to copy quite > some classes. > It seems the introduction of commons-fileupload and commons-io as > dependencies in 7.0.0 didn't lead to any complains so far. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, Nov 9, 2015 at 10:34 AM, Martijn Dashorst < > [email protected]> wrote: > >> One of the problems we ran into while fixing 6021 was the ability to >> use a Linked[Hash]Map. The default JDK version doesn't have any public >> or protected API to give us the previous and next entries. We need >> those to retrieve the next element when removing a child from a markup >> container. >> >> Unfortunately the JDK collections don't have any extensibility that >> would allow us to graft those missing methods upon the existing >> collections. >> >> Commons Collections provides a LinkedMap class that does give us those >> methods. Unfortunately this forces us to add a core dependency, or we >> should copy the specific code into our project. >> >> Adding a dependency is bad because it adds more stuff to track--not >> just for us, but for our users as well--, provides additional >> headaches (as you may have noticed, there's an deserialization issue >> with commons-collections). >> >> Moving the code from com-col to Wicket is also bad, as we take on the >> maintenance burden, the code in question takes about 30-ish classes to >> copy, and we duplicate code that is available from elsewhere >> (duplication is bad mkay) >> >> Emond's suggestion is to move the code, strip it of all that we don't >> need and maintain that ourselves. I'd like to add that we should make >> that code package private or name it such that it doesn't conflict >> with com-col on a class name base. >> >> But before we go on that path, we'd like to hear if folks have better >> ideas? >> >> Martijn >>
