Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

[Thomas Neidhart]

On 11/12/2015 07:14 PM, Jörg Schaible wrote:
> Hi Thomas,
> 
> Thomas Neidhart wrote:
> 
>> Hi all,
>>
>> in order to provide a work-around for the known remote code exploit via
>> java de-serialization of malicious InvokerTransformer instances, I would
>> like to start a vote to release Commons Collections 3.2.2 based on RC2.
>>
>> Notes:
>>
>>  * the site will not be published, it just serves as a reference to
>> access the various reports. After a successful vote, the current 4.X
>> branch site will be updated with relevant information and published.
>>
>>  * some tests might fail with various IBM JDK 6 JREs, these are known
>> issues and have been worked-around in the 4.X branch but are not
>> back-ported to this release.
>>
>>  * Collections 3.2.2 can not be compiled with JDK 8 due to a name clash
>> with a newly introduced default method in the Map interface.
>>
>>  * the collections-testframework.jar that has been published in previous
>> versions is not included in this release
>>
>>
>> Changes from RC1:
>>
>>  * fixed RAT report
>>  * fixed NOTICE file
>>  * improve the security fix: it has been made symmetric in the sense
>>that also the serialization of an unsafe class is disabled by
>>default and will result in an exception
>>  * changed the system property to re-enable serialization of unsafe
>>classes. It is now
>>"org.apache.commons.collections.enableUnsafeSerialization"
>>  * all classes in the functor package which (based on current
>>knowledge) have to be considered unsafe cannot be serialized/
>>de-serialized any more by default. This includes the following
>>classes:
>>
>>  ** CloneTransformer
>>  ** PrototypeFactory (inner classes
>>   PrototypeCloneFactory and
>>   PrototypeSerializationFactory)
>>  ** InstantiateFactory
>>  ** InstantiateTransformer
>>  ** ForClosure
>>  ** WhileClosure
>>  ** InvokerTransformer
>>
>>
>>
>> Collections 3.2.2 RC2 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/collections/
>> (svn revision 11147)
>>
>> Maven artifacts are here:
>>
>>
> https://repository.apache.org/content/repositories/orgapachecommons-1116/commons-collections/commons-collections/3.2.2/
>>
>> Details of changes since 3.2.1 are in the release notes:
>>
>> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt
>>
>> http://people.apache.org/builds/commons/collections/3.2.2/RC2/changes-report.html
>>
>> The tag is here:
>>
>>
> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC2
>> (svn revision 1713883)
>>
>> Site:
>> http://people.apache.org/builds/commons/collections/3.2.2/RC2/
>>
>> Clirr Report (compared to 3.2.1):
>>
>> http://people.apache.org/builds/commons/collections/3.2.2/RC2/clirr-report.html
>>
>> RAT Report:
>>
>> http://people.apache.org/builds/commons/collections/3.2.2/RC2/rat-report.html
>>
>> KEYS:
>>   https://www.apache.org/dist/commons/KEYS
>>
>> Please review the release candidate and vote.
>>
>>
>> Considering that this is a security related release and that RC1 did not
>> show any functional problems with the release, I plan to close this vote
>> in 24 from now, i.e. after 1800 GMT 12-November 2015
>>
>>   [ ] +1 Release these artifacts
>>   [ ] +0 OK, but...
>>   [ ] -0 OK, but really should fix...
>>   [ ] -1 I oppose this release because...
> 
> -1,
> 
> sorry, but there's a regression
> 
> The package claims to be compatible with Java 1.3. Well, I don't have 1.3 
> anymore, but 1.4. And I can build CC-3.2.1 and run all tests with Blackdown 
> JDK 1.4 and Maven 2.0.11.
> 
> For CC-3.2.2 I have to use at least Java 5 and Maven 3.0(.5):
> 
> - Using java-1.4 profile: Build fails, because tests no longer compile
> - Sun JDK 1.5: TestAllPackages fails due to SecurityException:
> == %< ==
> Running org.apache.commons.collections.TestAllPackages
> java.lang.SecurityException
> at 
> org.apache.commons.collections.TestExtendedProperties$1.checkPropertyAccess(TestExtendedProperties.java:322)
> at java.lang.System.getProperty(System.java:628)
> at 
> sun.security.action.GetPropertyAction.run(GetPropertyAction.java:66)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.io.PrintWriter.(PrintWriter.java:77)
> at java.io.PrintWriter.(PrintWriter.java:61)
> at 
> org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:56)
> at 
> org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:119)
> == %< ==
> - Sun JDK 1.6: OK
> - Oracle JDK 1.7: OK
> - IBM JDK 1.5: OK (!!)
> - IBM JDK 1.6 (J9 2.4): fails (as expected, same for CC-3.2.1)
> - IBM JDK 1.7: OK (!!)
> - IcedTea 6 (OpenJDK): 

Fwd: svn commit: r1714114 - /commons/proper/io/trunk/RELEASE-NOTES.txt

[Gary Gregory]

I do not think one of the contributor's name need to be in ALL CAPS.

Gary

-- Forwarded message --
From: 
Date: Thu, Nov 12, 2015 at 12:17 PM
Subject: svn commit: r1714114 - /commons/proper/io/trunk/RELEASE-NOTES.txt
To: comm...@commons.apache.org


Author: krosenvold
Date: Thu Nov 12 20:17:39 2015
New Revision: 1714114

URL: http://svn.apache.org/viewvc?rev=1714114=rev
Log:
Release notes

Modified:
commons/proper/io/trunk/RELEASE-NOTES.txt

Modified: commons/proper/io/trunk/RELEASE-NOTES.txt
URL:
http://svn.apache.org/viewvc/commons/proper/io/trunk/RELEASE-NOTES.txt?rev=1714114=1714113=1714114=diff
==
--- commons/proper/io/trunk/RELEASE-NOTES.txt (original)
+++ commons/proper/io/trunk/RELEASE-NOTES.txt Thu Nov 12 20:17:39 2015
@@ -1,6 +1,6 @@

 Apache Commons IO
-Version 2.4
+Version 2.5
 Release Notes

 INTRODUCTION:
@@ -9,35 +9,153 @@ Commons IO is a package of Java utility
 Classes in this package are considered to be so standard and of such high
 reuse as to justify existence in java.io.

-The Commons IO library contains utility classes, stream implementations,
file filters,
+The Apache Commons IO library contains utility classes, stream
implementations, file filters,
 file comparators, endian transformation classes, and much more.

 ==
-Apache Commons IO Version 2.4
+Apache Commons IO Version 2.5
 ==
 New features and bug fixes.

 Changes in this version include:

 New features:
-o IO-269:  Tailer locks file from deletion/rename on Windows. Thanks to
sebb.
-o IO-333:  Export OSGi packages at version 1.x in addition to 2.x. Thanks
to fmeschbe.
-o IO-320:  Add XmlStreamReader support for UTF-32. Thanks to ggregory.
-o IO-331:  BOMInputStream wrongly detects UTF-32LE_BOM files as
UTF-16LE_BOM files in method getBOM(). Thanks to ggregory.
-o IO-327:  Add byteCountToDisplaySize(BigInteger). Thanks to ggregory.
-o IO-326:  Add new FileUtils.sizeOf[Directory] APIs to return BigInteger.
Thanks to ggregory, kinow.
-o IO-325:  Add IOUtils.toByteArray methods to work with URL and URI.
Thanks to raviprak.
-o IO-324:  Add missing Charset sister APIs to method that take a String
charset name. Thanks to raviprak.
+o IO-471:  Support for additional encodings in ReversedLinesFileReader
Thanks to Leandro Reis.
+o IO-425:  Setter method for threshold on ThresholdingOutputStream Thanks
to Craig Swank.
+o IO-406:  Introduce new class AppendableOutputStream Thanks to Niall
Pemberton.
+o IO-459:  Add WindowsLineEndingInputStream and UnixLineEndingInputStream.
Thanks to Kristian Rosenvold.
+o IO-457:  Add a BoundedReader, a wrapper that can be used to constrain
access
+to an underlying stream when used with mark/reset -
+to avoid overflowing the mark limit of the underlying buffer.
Thanks to Kristian Rosenvold.
+o IO-426:  Add API IOUtils.closeQuietly(Closeable...)
+o IO-410:  Readfully() That Returns A Byte Array Thanks to BELUGA BEHR.
+o IO-395:  Overload IOUtils buffer methods to accept buffer size Thanks to
BELUGA BEHR.
+o IO-382:  Chunked IO for large arrays.
+ Added writeChunked(byte[], OutputStream) and writeChunked(char[]
Writer)
+ Added ChunkedOutputStream, ChunkedWriter
+o IO-233:  Add Methods for Buffering Streams/Writers To IOUtils
+ Added overloaded buffer() methods - see also IO-330
+o IO-330:  IOUtils#toBufferedOutputStream/toBufferedWriter to
conditionally wrap the output
+ Added overloaded buffer() methods - see also IO-233
+o IO-381:  Add FileUtils.copyInputStreamToFile API with option to leave
the source open.
+See copyInputStreamToFile(final InputStream source, final File
destination, boolean closeSource)
+o IO-379:  CharSequenceInputStream - add tests for available()
+ Fix code so it really does reflect a minimum available.
+o IO-346:  Add ByteArrayOutputStream.toInputStream()
+o IO-341:  A constant for holding the BOM character (U+FEFF)
+o IO-361:  Add API FileUtils.forceMkdirsParent().
+o IO-360:  Add API Charsets.requiredCharsets().
+o IO-359:  Add IOUtils.skip and skipFully(ReadableByteChannel, long).
Thanks to yukoba.
+o IO-358:  Add IOUtils.read and readFully(ReadableByteChannel, ByteBuffer
buffer). Thanks to yukoba.
+o IO-353:  Add API IOUtils.copy(InputStream, OutputStream, int) Thanks to
ggregory.
+o IO-349:  Add API with array offset and length argument to
FileUtils.writeByteArrayToFile. Thanks to scop.
+o IO-348:  Missing information in IllegalArgumentException thrown by
org.apache.commons.io.FileUtils#validateListFilesParameters. Thanks to
plcstpierre.
+o IO-345:  Supply a hook method allowing Tailer actively determining stop
condition. Thanks to mkresse.
+o IO-437:  Make IOUtils.EOF public and reuse it in various classes.
+
+Fixed Bugs:
+o IO-446:  adds an 

Re: [COLLECTIONS] Bad press on twitter following serialization issue

[Gary Gregory]

I think I saw a /. article about this yesterday... yikes.

G

On Wed, Nov 11, 2015 at 12:30 AM, Bernd Eckenfels 
wrote:

> Hello,
>
> BTW Oracle issued a "Strange" Security alert:
>
> 2015-4852 was released on November 10th, 2015.
>
> This vulnerability, which involves the Apache Commons and Oracle WebLogic
> Server, has received a CVSS Base Score of 7.5.
> ...
>
> Bernd
>
> > Am 08.11.2015 um 10:41 schrieb Benedikt Ritter :
> >
> > Hi,
> >
> > there is a lot of bad talk going on at twitter [1,2,3] and I'm wondering
> > whether we should respond to this via the Apache blog.
> >
> > Thoughts?
> > Benedikt
> >
> > [1] https://twitter.com/JustineTunney/status/662937508980723712
> > [2] https://twitter.com/kennwhite/status/662709833464872960
> > [3] https://twitter.com/jodastephen/status/663253106751180800
> >
> >
> > --
> > http://people.apache.org/~britter/
> > http://www.systemoutprintln.de/
> > http://twitter.com/BenediktRitter
> > http://github.com/britter
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

[Stefan Bodewig]

On 2015-11-11, Thomas Neidhart wrote:

> Please review the release candidate and vote.

+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

[Stefan Bodewig]

On 2015-11-12, Phil Steitz wrote:

>> On Nov 11, 2015, at 12:05 PM, Gary Gregory  wrote:

>> -1

> That is frankly ridiculous.

Couldn't agree more.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[CANCEL][VOTE] Release Commons Collections 3.2.2 Based on RC2

[Thomas Neidhart]

On 11/11/2015 05:27 PM, Thomas Neidhart wrote:
> Hi all,
> 
> in order to provide a work-around for the known remote code exploit via
> java de-serialization of malicious InvokerTransformer instances, I would
> like to start a vote to release Commons Collections 3.2.2 based on RC2.
> 
> Notes:
> 
>  * the site will not be published, it just serves as a reference to
> access the various reports. After a successful vote, the current 4.X
> branch site will be updated with relevant information and published.
> 
>  * some tests might fail with various IBM JDK 6 JREs, these are known
> issues and have been worked-around in the 4.X branch but are not
> back-ported to this release.
> 
>  * Collections 3.2.2 can not be compiled with JDK 8 due to a name clash
> with a newly introduced default method in the Map interface.
> 
>  * the collections-testframework.jar that has been published in previous
> versions is not included in this release
> 
> 
> Changes from RC1:
> 
>  * fixed RAT report
>  * fixed NOTICE file
>  * improve the security fix: it has been made symmetric in the sense
>that also the serialization of an unsafe class is disabled by
>default and will result in an exception
>  * changed the system property to re-enable serialization of unsafe
>classes. It is now
>"org.apache.commons.collections.enableUnsafeSerialization"
>  * all classes in the functor package which (based on current
>knowledge) have to be considered unsafe cannot be serialized/
>de-serialized any more by default. This includes the following
>classes:
> 
>  ** CloneTransformer
>  ** PrototypeFactory (inner classes
>   PrototypeCloneFactory and
>   PrototypeSerializationFactory)
>  ** InstantiateFactory
>  ** InstantiateTransformer
>  ** ForClosure
>  ** WhileClosure
>  ** InvokerTransformer
> 
> 
> 
> Collections 3.2.2 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/collections/
> (svn revision 11147)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1116/commons-collections/commons-collections/3.2.2/
> 
> Details of changes since 3.2.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC2/changes-report.html
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC2
> (svn revision 1713883)
> 
> Site:
> http://people.apache.org/builds/commons/collections/3.2.2/RC2/
> 
> Clirr Report (compared to 3.2.1):
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC2/clirr-report.html
> 
> RAT Report:
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC2/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> 
> 
> Considering that this is a security related release and that RC1 did not
> show any functional problems with the release, I plan to close this vote
> in 24 from now, i.e. after 1800 GMT 12-November 2015
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...

The vote is cancelled to fix the test errors on some java versions.

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release Commons Collections 3.2.2 Based on RC3

[Thomas Neidhart]

Hi all,

in order to provide a work-around for the known remote code exploit via
java de-serialization of malicious InvokerTransformer instances, I would
like to start a vote to release Commons Collections 3.2.2 based on RC3.

Notes:

 * the site will not be published, it just serves as a reference to
access the various reports. After a successful vote, the current 4.X
branch site will be updated with relevant information and published.

 * some tests might fail with various IBM JDK 6 JREs, these are known
issues and have been worked-around in the 4.X branch but are not
back-ported to this release.

 * Collections 3.2.2 can not be compiled with JDK 8 due to a name clash
with a newly introduced default method in the Map interface.

 * the collections-testframework.jar that has been published in previous
versions is not included in this release

Changes from RC2:

 * fixed false positives in RAT report
 * fixed test execution and compilation problems with JDK 1.4 and 1.5

Changes from RC1:

 * fixed RAT report
 * fixed NOTICE file
 * improve the security fix: it has been made symmetric in the sense
   that also the serialization of an unsafe class is disabled by
   default and will result in an exception
 * changed the system property to re-enable serialization of unsafe
   classes. It is now
   "org.apache.commons.collections.enableUnsafeSerialization"
 * all classes in the functor package which (based on current
   knowledge) have to be considered unsafe cannot be serialized/
   de-serialized any more by default. This includes the following
   classes:

 ** CloneTransformer
 ** PrototypeFactory (inner classes
  PrototypeCloneFactory and
  PrototypeSerializationFactory)
 ** InstantiateFactory
 ** InstantiateTransformer
 ** ForClosure
 ** WhileClosure
 ** InvokerTransformer



Collections 3.2.2 RC3 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/collections/
(svn revision 11167)

Maven artifacts are here:

https://repository.apache.org/content/repositories/orgapachecommons-1117/commons-collections/commons-collections/3.2.2/

Details of changes since 3.2.1 are in the release notes:

https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt

http://people.apache.org/builds/commons/collections/3.2.2/RC3/changes-report.html

The tag is here:

https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC3
(svn revision 1714131)

Site:
http://people.apache.org/builds/commons/collections/3.2.2/RC3/

Clirr Report (compared to 3.2.1):

http://people.apache.org/builds/commons/collections/3.2.2/RC3/clirr-report.html

RAT Report:

http://people.apache.org/builds/commons/collections/3.2.2/RC3/rat-report.html

KEYS:
  https://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.


Considering that this is a security related release and that RC2 did not
show any functional problems with the release, I plan to close this vote
in 24h from now, i.e. after 0100 GMT 14-November 2015

  [ ] +1 Release these artifacts
  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks,

Thomas

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

[luc]

Le 2015-11-12 10:18, Stefan Bodewig a écrit :

On 2015-11-11, Thomas Neidhart wrote:


Please review the release candidate and vote.



+1 for the release.

Luc



+1

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [POOL] Improving the borrow/return process with anonymous functions

[Gary Gregory]

Updating to Java 8 would be fine with me. You could write a [poll] email
thread the ML to gauge interest.

Gary

On Thu, Nov 12, 2015 at 11:03 AM, Cory Klein  wrote:

> > The first hurdle here is that pool is not on Java 8. But this could be
> done
> > with other facilities like Runnable, Callable, maybe even an executor.
>
> Although Callable wouldn't be as elegant as lambdas, it would
> definitely be possible. The consumer could define a Callable:
>
> class ResourceCallable implements Callable {
>   private MyResource resource;
>   public ResourceCallable(MyResource resource) {
> this.resource = resource;
>   }
>
>   public String call() {
> return doSomething();
>   }
>
>   public String doSomething() {
>   ...
>   }
> }
>
> Then it passes that callable's type into run with its return type:
>
>   String result = objectPool.run(ResourceCallable.class, String.class)
>
> Then maybe something like this for the definition of run:
>
> public class  ObjectPool {
>   ...
>   public  U run(Class callableType, Class returnType) {
> // Leaving out exception handling for brevity
> T obj = borrowObject();
> S callable = callableType.getConstructor().newInstance(obj);
> U result = callable.call();
> returnObject(obj);
> return result;
>   }
> }
>
> So yea, not quite as pretty as with lambdas. Is it expensive to
> upgrade the Java version of a commons lib like pool? Java 8 will be 2
> years old in March, but I'm sure there would be plenty of people
> unable to consume a version that jumps from 1.6 to 1.8.
>
> Looks like the last time we upgraded was from 1.5->1.6 in Feb 2012
> because "1.5 is out of support unless you pay for it" (git sha
> d44c8f6).
>
> On Thu, Nov 12, 2015 at 10:55 AM, Gary Gregory 
> wrote:
> > The first hurdle here is that pool is not on Java 8. But this could be
> done
> > with other facilities like Runnable, Callable, maybe even an executor.
> >
> > Gary
> > On Nov 12, 2015 9:47 AM, "Cory Klein"  wrote:
> >
> >> First off, hello! My name is Cory Klein and this marks my first
> >> interaction with this group. I've read through the email guidelines
> >> and I think I have something productive to discuss here.
> >>
> >> In looking at GenericObjectPool I came across a process that I believe
> >> could be improved upon and I wanted to get some early feedback on this
> >> approach before investing the time to create a full pull request.
> >>
> >> The general approach for using an object pool is to borrow an object,
> >> use it to do something, and then return it. For example:
> >>
> >> Resource resource = objectPool.borrowObject();
> >> String result = doSomething(resource);
> >> objectPool.returnObject(resource);
> >>
> >> In this case, objectPool owns instances of Resource and lends them
> >> out. However, the object pool abstraction gets slightly leaky when you
> >> consider that the consumer has a responsibility to return the object,
> >> and other consumers might be adversely affected if objects aren't
> >> returned properly.
> >>
> >> I propose augmenting ObjectPool with the following method. This code
> >> is merely demonstrative and not intended to be final:
> >>
> >> public class  ObjectPool {
> >> ...
> >>
> >> public R run(Function function) {
> >> T obj = null;
> >> try {
> >> obj = borrowObject();
> >> } catch (Exception e) {
> >> throw new RuntimeException("Unable to get object from
> pool");
> >> }
> >> R returnVal = null;
> >> try {
> >> returnVal = function(T);
> >> } catch (Exception e) {
> >> throw new RuntimeException("Supplied lambda produced an
> >> exception");
> >> } finally {
> >> this.returnObject(obj);
> >> return returnVal;
> >> }
> >> }
> >> }
> >>
> >> With this idea, consumers can instead provide the object pool with a
> >> function to run using the required resource, leaving the object pool
> >> complete ownership of the resource and ensuring that resources can
> >> always be returned to the pool. The borrow/return example from above
> >> becomes merely:
> >>
> >> String result = objectPool.run((resource) -> doSomething(resource));
> >>
> >> In summary, some positive reasons I can think of to make this change
> are:
> >>
> >> * Improve a leaky abstraction
> >> * Less code needed on the consuming side
> >> * Improved reliability
> >>
> >> I'm having a harder time coming up with reasons why this change is
> >> bad, but I think this may be due to a lack of intimacy with the
> >> library as it exists now. Are there any reasons that are immediately
> >> apparent to you?
> >>
> >> Thanks,
> >>
> >> Cory Klein
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

[Gary Gregory]

On Nov 11, 2015 11:45 PM, "Emmanuel Bourg"  wrote:
>
> Le 12/11/2015 04:39, Phil Steitz a écrit :
>
> > That is frankly ridiculous.  To -1 a release based on false positive
report about files not included in the release is absurd.
>
> I agree with Phil. We are releasing code, not reports.

Keep in mind that we release sources and provide binaries as a convenience.
I consider it cleaner and proper to have all files in the source package
cleanly licensed and producing a clean build.

Gary

>
> Emmanuel
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

[POOL] Improving the borrow/return process with anonymous functions

[Cory Klein]

First off, hello! My name is Cory Klein and this marks my first
interaction with this group. I've read through the email guidelines
and I think I have something productive to discuss here.

In looking at GenericObjectPool I came across a process that I believe
could be improved upon and I wanted to get some early feedback on this
approach before investing the time to create a full pull request.

The general approach for using an object pool is to borrow an object,
use it to do something, and then return it. For example:

Resource resource = objectPool.borrowObject();
String result = doSomething(resource);
objectPool.returnObject(resource);

In this case, objectPool owns instances of Resource and lends them
out. However, the object pool abstraction gets slightly leaky when you
consider that the consumer has a responsibility to return the object,
and other consumers might be adversely affected if objects aren't
returned properly.

I propose augmenting ObjectPool with the following method. This code
is merely demonstrative and not intended to be final:

public class  ObjectPool {
...

public R run(Function function) {
T obj = null;
try {
obj = borrowObject();
} catch (Exception e) {
throw new RuntimeException("Unable to get object from pool");
}
R returnVal = null;
try {
returnVal = function(T);
} catch (Exception e) {
throw new RuntimeException("Supplied lambda produced an exception");
} finally {
this.returnObject(obj);
return returnVal;
}
}
}

With this idea, consumers can instead provide the object pool with a
function to run using the required resource, leaving the object pool
complete ownership of the resource and ensuring that resources can
always be returned to the pool. The borrow/return example from above
becomes merely:

String result = objectPool.run((resource) -> doSomething(resource));

In summary, some positive reasons I can think of to make this change are:

* Improve a leaky abstraction
* Less code needed on the consuming side
* Improved reliability

I'm having a harder time coming up with reasons why this change is
bad, but I think this may be due to a lack of intimacy with the
library as it exists now. Are there any reasons that are immediately
apparent to you?

Thanks,

Cory Klein

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [POOL] Improving the borrow/return process with anonymous functions

[Gary Gregory]

The first hurdle here is that pool is not on Java 8. But this could be done
with other facilities like Runnable, Callable, maybe even an executor.

Gary
On Nov 12, 2015 9:47 AM, "Cory Klein"  wrote:

> First off, hello! My name is Cory Klein and this marks my first
> interaction with this group. I've read through the email guidelines
> and I think I have something productive to discuss here.
>
> In looking at GenericObjectPool I came across a process that I believe
> could be improved upon and I wanted to get some early feedback on this
> approach before investing the time to create a full pull request.
>
> The general approach for using an object pool is to borrow an object,
> use it to do something, and then return it. For example:
>
> Resource resource = objectPool.borrowObject();
> String result = doSomething(resource);
> objectPool.returnObject(resource);
>
> In this case, objectPool owns instances of Resource and lends them
> out. However, the object pool abstraction gets slightly leaky when you
> consider that the consumer has a responsibility to return the object,
> and other consumers might be adversely affected if objects aren't
> returned properly.
>
> I propose augmenting ObjectPool with the following method. This code
> is merely demonstrative and not intended to be final:
>
> public class  ObjectPool {
> ...
>
> public R run(Function function) {
> T obj = null;
> try {
> obj = borrowObject();
> } catch (Exception e) {
> throw new RuntimeException("Unable to get object from pool");
> }
> R returnVal = null;
> try {
> returnVal = function(T);
> } catch (Exception e) {
> throw new RuntimeException("Supplied lambda produced an
> exception");
> } finally {
> this.returnObject(obj);
> return returnVal;
> }
> }
> }
>
> With this idea, consumers can instead provide the object pool with a
> function to run using the required resource, leaving the object pool
> complete ownership of the resource and ensuring that resources can
> always be returned to the pool. The borrow/return example from above
> becomes merely:
>
> String result = objectPool.run((resource) -> doSomething(resource));
>
> In summary, some positive reasons I can think of to make this change are:
>
> * Improve a leaky abstraction
> * Less code needed on the consuming side
> * Improved reliability
>
> I'm having a harder time coming up with reasons why this change is
> bad, but I think this may be due to a lack of intimacy with the
> library as it exists now. Are there any reasons that are immediately
> apparent to you?
>
> Thanks,
>
> Cory Klein
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

[Jörg Schaible]

Hi Thomas,

Thomas Neidhart wrote:

> Hi all,
> 
> in order to provide a work-around for the known remote code exploit via
> java de-serialization of malicious InvokerTransformer instances, I would
> like to start a vote to release Commons Collections 3.2.2 based on RC2.
> 
> Notes:
> 
>  * the site will not be published, it just serves as a reference to
> access the various reports. After a successful vote, the current 4.X
> branch site will be updated with relevant information and published.
> 
>  * some tests might fail with various IBM JDK 6 JREs, these are known
> issues and have been worked-around in the 4.X branch but are not
> back-ported to this release.
> 
>  * Collections 3.2.2 can not be compiled with JDK 8 due to a name clash
> with a newly introduced default method in the Map interface.
> 
>  * the collections-testframework.jar that has been published in previous
> versions is not included in this release
> 
> 
> Changes from RC1:
> 
>  * fixed RAT report
>  * fixed NOTICE file
>  * improve the security fix: it has been made symmetric in the sense
>that also the serialization of an unsafe class is disabled by
>default and will result in an exception
>  * changed the system property to re-enable serialization of unsafe
>classes. It is now
>"org.apache.commons.collections.enableUnsafeSerialization"
>  * all classes in the functor package which (based on current
>knowledge) have to be considered unsafe cannot be serialized/
>de-serialized any more by default. This includes the following
>classes:
> 
>  ** CloneTransformer
>  ** PrototypeFactory (inner classes
>   PrototypeCloneFactory and
>   PrototypeSerializationFactory)
>  ** InstantiateFactory
>  ** InstantiateTransformer
>  ** ForClosure
>  ** WhileClosure
>  ** InvokerTransformer
> 
> 
> 
> Collections 3.2.2 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/collections/
> (svn revision 11147)
> 
> Maven artifacts are here:
> 
> 
https://repository.apache.org/content/repositories/orgapachecommons-1116/commons-collections/commons-collections/3.2.2/
> 
> Details of changes since 3.2.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC2/changes-report.html
> 
> The tag is here:
> 
> 
https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC2
> (svn revision 1713883)
> 
> Site:
> http://people.apache.org/builds/commons/collections/3.2.2/RC2/
> 
> Clirr Report (compared to 3.2.1):
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC2/clirr-report.html
> 
> RAT Report:
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC2/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> 
> 
> Considering that this is a security related release and that RC1 did not
> show any functional problems with the release, I plan to close this vote
> in 24 from now, i.e. after 1800 GMT 12-November 2015
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...

-1,

sorry, but there's a regression

The package claims to be compatible with Java 1.3. Well, I don't have 1.3 
anymore, but 1.4. And I can build CC-3.2.1 and run all tests with Blackdown 
JDK 1.4 and Maven 2.0.11.

For CC-3.2.2 I have to use at least Java 5 and Maven 3.0(.5):

- Using java-1.4 profile: Build fails, because tests no longer compile
- Sun JDK 1.5: TestAllPackages fails due to SecurityException:
== %< ==
Running org.apache.commons.collections.TestAllPackages
java.lang.SecurityException
at 
org.apache.commons.collections.TestExtendedProperties$1.checkPropertyAccess(TestExtendedProperties.java:322)
at java.lang.System.getProperty(System.java:628)
at 
sun.security.action.GetPropertyAction.run(GetPropertyAction.java:66)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.PrintWriter.(PrintWriter.java:77)
at java.io.PrintWriter.(PrintWriter.java:61)
at 
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:56)
at 
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:119)
== %< ==
- Sun JDK 1.6: OK
- Oracle JDK 1.7: OK
- IBM JDK 1.5: OK (!!)
- IBM JDK 1.6 (J9 2.4): fails (as expected, same for CC-3.2.1)
- IBM JDK 1.7: OK (!!)
- IcedTea 6 (OpenJDK): TestAllPackages fails due to SecurityException:
== %< ==
Running org.apache.commons.collections.TestAllPackages
java.lang.SecurityException
at 

Re: [POOL] Improving the borrow/return process with anonymous functions

[Cory Klein]

> The first hurdle here is that pool is not on Java 8. But this could be done
> with other facilities like Runnable, Callable, maybe even an executor.

Although Callable wouldn't be as elegant as lambdas, it would
definitely be possible. The consumer could define a Callable:

class ResourceCallable implements Callable {
  private MyResource resource;
  public ResourceCallable(MyResource resource) {
this.resource = resource;
  }

  public String call() {
return doSomething();
  }

  public String doSomething() {
  ...
  }
}

Then it passes that callable's type into run with its return type:

  String result = objectPool.run(ResourceCallable.class, String.class)

Then maybe something like this for the definition of run:

public class  ObjectPool {
  ...
  public  U run(Class callableType, Class returnType) {
// Leaving out exception handling for brevity
T obj = borrowObject();
S callable = callableType.getConstructor().newInstance(obj);
U result = callable.call();
returnObject(obj);
return result;
  }
}

So yea, not quite as pretty as with lambdas. Is it expensive to
upgrade the Java version of a commons lib like pool? Java 8 will be 2
years old in March, but I'm sure there would be plenty of people
unable to consume a version that jumps from 1.6 to 1.8.

Looks like the last time we upgraded was from 1.5->1.6 in Feb 2012
because "1.5 is out of support unless you pay for it" (git sha
d44c8f6).

On Thu, Nov 12, 2015 at 10:55 AM, Gary Gregory  wrote:
> The first hurdle here is that pool is not on Java 8. But this could be done
> with other facilities like Runnable, Callable, maybe even an executor.
>
> Gary
> On Nov 12, 2015 9:47 AM, "Cory Klein"  wrote:
>
>> First off, hello! My name is Cory Klein and this marks my first
>> interaction with this group. I've read through the email guidelines
>> and I think I have something productive to discuss here.
>>
>> In looking at GenericObjectPool I came across a process that I believe
>> could be improved upon and I wanted to get some early feedback on this
>> approach before investing the time to create a full pull request.
>>
>> The general approach for using an object pool is to borrow an object,
>> use it to do something, and then return it. For example:
>>
>> Resource resource = objectPool.borrowObject();
>> String result = doSomething(resource);
>> objectPool.returnObject(resource);
>>
>> In this case, objectPool owns instances of Resource and lends them
>> out. However, the object pool abstraction gets slightly leaky when you
>> consider that the consumer has a responsibility to return the object,
>> and other consumers might be adversely affected if objects aren't
>> returned properly.
>>
>> I propose augmenting ObjectPool with the following method. This code
>> is merely demonstrative and not intended to be final:
>>
>> public class  ObjectPool {
>> ...
>>
>> public R run(Function function) {
>> T obj = null;
>> try {
>> obj = borrowObject();
>> } catch (Exception e) {
>> throw new RuntimeException("Unable to get object from pool");
>> }
>> R returnVal = null;
>> try {
>> returnVal = function(T);
>> } catch (Exception e) {
>> throw new RuntimeException("Supplied lambda produced an
>> exception");
>> } finally {
>> this.returnObject(obj);
>> return returnVal;
>> }
>> }
>> }
>>
>> With this idea, consumers can instead provide the object pool with a
>> function to run using the required resource, leaving the object pool
>> complete ownership of the resource and ensuring that resources can
>> always be returned to the pool. The borrow/return example from above
>> becomes merely:
>>
>> String result = objectPool.run((resource) -> doSomething(resource));
>>
>> In summary, some positive reasons I can think of to make this change are:
>>
>> * Improve a leaky abstraction
>> * Less code needed on the consuming side
>> * Improved reliability
>>
>> I'm having a harder time coming up with reasons why this change is
>> bad, but I think this may be due to a lack of intimacy with the
>> library as it exists now. Are there any reasons that are immediately
>> apparent to you?
>>
>> Thanks,
>>
>> Cory Klein
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org