Oh! I'm sorry :-/ - I was not following the whole discussion - just read about collections and saw this article.
kind regards Tobias > Am 10.11.2015 um 23:31 schrieb Martin Grigorov <mgrigo...@apache.org>: > > You watch out :p > Martijn mentioned it in his mail: (as you may have noticed, there's an > deserialization issue with commons-collections). > And here is the answer: > https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Tue, Nov 10, 2015 at 11:18 PM, Tobias Soloschenko < > tobiassolosche...@googlemail.com> wrote: > >> 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 <mgrigo...@apache.org>: >>> >>> +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 < >>> martijn.dasho...@gmail.com> 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 >>
