date:20140528

Re: [VOTE] Release BeanUtils 1.9.2 based on RC1

2014-05-28 Thread Thomas Neidhart

On Mon, May 26, 2014 at 9:39 PM, Oliver Heger
wrote:

> This is a vote to release Commons BeanUtils 1.9.2 based on the first RC.
> There was a fix related to a security issue which should now be made
> available.
>
> BeanUtils 1.9.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/beanutils/ (svn
> revision 5419)
>
>   Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1032/
>
>   Details of changes since 1.9.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/beanutils/RELEASE-NOTES.txt
>
> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/changes-report.html
>
>   The tag is here:
>
>
> http://svn.apache.org/repos/asf/commons/proper/beanutils/tags/BEANUTILS_1_9_2_RC1/
> (svn 1597453)
>
>   Site:
> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/
>   (note some *relative* links are broken and some new directories are
>   not yet created - these will be OK once the site is deployed)
>
>   KEYS:
>   http://www.apache.org/dist/commons/KEYS
>
> Note: There is a known issue with some tests related to memory leak
> detection failing on some environments. This has already been the case
> for the previous release; there were no changes in this area.
>
>   Please review the release candidate and vote.
>   This vote will close no sooner that 72 hours from now, i.e. after 2000
> GMT 29-May 2014
>

[X] +1 Release these artifacts

Good job!

Thomas

Re: [VOTE] Release BeanUtils 1.9.2 based on RC1

2014-05-28 Thread Emmanuel Bourg

+1

Checked with OpenJDK 7 and 8 on Debian

Emmanuel Bourg


Le 26/05/2014 21:39, Oliver Heger a écrit :
> This is a vote to release Commons BeanUtils 1.9.2 based on the first RC.
> There was a fix related to a security issue which should now be made
> available.
> 
> BeanUtils 1.9.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/beanutils/ (svn
> revision 5419)
> 
>   Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1032/
> 
>   Details of changes since 1.9.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/beanutils/RELEASE-NOTES.txt
> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/changes-report.html
> 
>   The tag is here:
> 
> http://svn.apache.org/repos/asf/commons/proper/beanutils/tags/BEANUTILS_1_9_2_RC1/
> (svn 1597453)
> 
>   Site:
> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/
>   (note some *relative* links are broken and some new directories are
>   not yet created - these will be OK once the site is deployed)
> 
>   KEYS:
>   http://www.apache.org/dist/commons/KEYS
> 
> Note: There is a known issue with some tests related to memory leak
> detection failing on some environments. This has already been the case
> for the previous release; there were no changes in this area.
> 
>   Please review the release candidate and vote.
>   This vote will close no sooner that 72 hours from now, i.e. after 2000
> GMT 29-May 2014
> 
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
>   Thanks!
> 
>   Oliver
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1594073 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/remote/server/ engine/memory/ engine/memory/util/

2014-05-28 Thread Romain Manni-Bucau

I'm convinced of it (why the comment was this way). I'll try to rework it
this week based on the LockFactory we spoke about in another thread.



Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-05-28 2:19 GMT+02:00 Phil Steitz :

> On 5/27/14, 11:17 AM, Benedikt Ritter wrote:
> >
> > Send from my mobile device
> >
> >> Am 13.05.2014 um 20:53 schrieb Phil Steitz :
> >>
> >>> On 5/12/14, 12:46 PM, rmannibu...@apache.org wrote:
> >>> Author: rmannibucau
> >>> Date: Mon May 12 19:46:08 2014
> >>> New Revision: 1594073
> >>>
> >>> URL: http://svn.apache.org/r1594073
> >>> Log:
> >>> removing a bunch of synchronized thanks to ConcurrentHashMap - still
> removeAll to review since it can be not that good but using any synch would
> make it slower and not scalable
> >>>
> >>> Modified:
> >>>
>  
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java
> >>>
>  
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
> >>>
>  
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/util/MemoryElementDescriptor.java
> >>>
> >>> Modified:
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java
> >>> URL:
> http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java?rev=1594073&r1=1594072&r2=1594073&view=diff
> >>>
> ==
> >>> ---
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java
> (original)
> >>> +++
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java
> Mon May 12 19:46:08 2014
> >>> @@ -81,7 +81,7 @@ public class RemoteCacheServerFactory
> >>>  * @return Returns the remoteCacheServer.
> >>>  */
> >>> @SuppressWarnings("unchecked") // Need cast to specific
> RemoteCacheServer
> >>> -public static 
> RemoteCacheServer getRemoteCacheServer()
> >>> +public static  RemoteCacheServer
> getRemoteCacheServer()
> >>> {
> >>> return (RemoteCacheServer)remoteCacheServer;
> >>> }
> >>>
> >>> Modified:
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
> >>> URL:
> http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java?rev=1594073&r1=1594072&r2=1594073&view=diff
> >>>
> ==
> >>> ---
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
> (original)
> >>> +++
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
> Mon May 12 19:46:08 2014
> >>> @@ -86,8 +86,11 @@ public abstract class AbstractDoubleLink
> >>>
> >>> /**
> >>>  * This is called by super initialize.
> >>> + *
> >>> + * NOTE: should return a thread safe map
> >>> + *
> >>>  * 
> >>> - * @return new Hashtable()
> >>> + * @return new ConcurrentHashMap()
> >>>  */
> >>> @Override
> >>> public Map> createMap()
> >>> @@ -109,19 +112,15 @@ public abstract class AbstractDoubleLink
> >>> {
> >>> putCnt++;
> >>>
> >>> -synchronized ( this )
> >> I am not really familiar with this code, so this could be needless
> >> concern; but removing this synch makes the adjustListForUpdate no
> >> longer atomic with the put below.  Is this OK?
> > Sorry, I seem to have missed the answer to this question. Was it okay to
> remove the synchronized?
>
> I don't know.  That's why I asked if there were a locking / data
> protection strategy implicit in the code and what data invariants
> need to be maintained.  This case should be straightforward.  You
> just need to convince yourself that the operations removed from the
> sync block can safely be performed by multiple threads with no
> atomicity guarantees.
>
> Phil
> >
> > Bene
> >
> >> Phil
> >>> -{
> >>> -// ABSTRACT
> >>> -MemoryElementDescriptor newNode =
> adjustListForUpdate( ce );
> >>> +MemoryElementDescriptor newNode = adjustListForUpdate(
> ce );
> >>>
> >>> -// this must be synchronized
> >>> -MemoryElementDescriptor oldNode = map.put(
> newNode.ce.getKey(), newNode );
> >>> +// this should be synchroniz

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-28 Thread Romain Manni-Bucau

2014-05-27 21:13 GMT+02:00 Thomas Vandahl :

> On 26.05.14 22:05, Romain Manni-Bucau wrote:
> > the point is putIfAbsent is costly but globally once (can be done
> > concurrently but this is ignorable at runtime). Only important thing is
> to
> > ensure then the system uses a single instance.
>
> Right, but what if the instance creates a file, socket or similar? If we
> want to do this we need to postpone all costly initialization into an
> initialize() method. In any case, I think this could simplified a lot by
> removing all separate managers.
>
>
well in this case locking should be where it is needed (around socket init
for instance). Idea I got was to say "avoid to force something you don't
want". Said otherwise don't put constraints before really needing it. Then
JCS is extensible so the question is where should be constraints? Can't
really be in the API IMHO since then impl can maybe be too constrainted.


> > The other point shocking me a bit is you need everything needs to be
> > processed sequentially. For a cache you globally want the last value. So
> > then you slow down the process cause you were not preempted.
>
> I'm open to suggestions on how to solve this. Feel free to experiment
> with JCSConcurrentCacheAccessUnitTest to see the effects. A put *must*
> be finished before the cached object can be accessed.
>
>
Hmm, I'm not 100% convinced of it actually. Sequentially that's true but
with multiple threads if that's not true that's not a big deal. Thanks for
the pointer on JCSConcurrentCacheAccessUnitTest, I'll check it.


> > I globally get the idea and we could use a LockFactory + ReentrantLock to
> > replace synchronized (would already be faster), this way we could even
> get
> > a NoLockFactory ;).
>
> I like the idea. It's certainly worth a try. My tests with locks did not
> show much improvement, though.
>
>
Ok I take this task. What I saw from my experiments was that with > 10
threads locks were better than synchronized but maybe JCS has something
making it wrong. I'll check it!


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

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

2014-05-28 Thread Romain Manni-Bucau

Found an IBM article showing globally what I experimented:
http://www.ibm.com/developerworks/java/library/j-jtp10264/

So I'll first add ReentrantLock where synchronized was used, then bench it
again and see depending performances if we need the LockFactory abstraction
or not.

Does it work for you?



Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-05-28 13:52 GMT+02:00 Romain Manni-Bucau :

>
> 2014-05-27 21:13 GMT+02:00 Thomas Vandahl :
>
> On 26.05.14 22:05, Romain Manni-Bucau wrote:
>> > the point is putIfAbsent is costly but globally once (can be done
>> > concurrently but this is ignorable at runtime). Only important thing is
>> to
>> > ensure then the system uses a single instance.
>>
>> Right, but what if the instance creates a file, socket or similar? If we
>> want to do this we need to postpone all costly initialization into an
>> initialize() method. In any case, I think this could simplified a lot by
>> removing all separate managers.
>>
>>
> well in this case locking should be where it is needed (around socket init
> for instance). Idea I got was to say "avoid to force something you don't
> want". Said otherwise don't put constraints before really needing it. Then
> JCS is extensible so the question is where should be constraints? Can't
> really be in the API IMHO since then impl can maybe be too constrainted.
>
>
>> > The other point shocking me a bit is you need everything needs to be
>> > processed sequentially. For a cache you globally want the last value. So
>> > then you slow down the process cause you were not preempted.
>>
>> I'm open to suggestions on how to solve this. Feel free to experiment
>> with JCSConcurrentCacheAccessUnitTest to see the effects. A put *must*
>> be finished before the cached object can be accessed.
>>
>>
> Hmm, I'm not 100% convinced of it actually. Sequentially that's true but
> with multiple threads if that's not true that's not a big deal. Thanks for
> the pointer on JCSConcurrentCacheAccessUnitTest, I'll check it.
>
>
>> > I globally get the idea and we could use a LockFactory + ReentrantLock
>> to
>> > replace synchronized (would already be faster), this way we could even
>> get
>> > a NoLockFactory ;).
>>
>> I like the idea. It's certainly worth a try. My tests with locks did not
>> show much improvement, though.
>>
>>
> Ok I take this task. What I saw from my experiments was that with > 10
> threads locks were better than synchronized but maybe JCS has something
> making it wrong. I'll check it!
>
>
>> Bye, Thomas.
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>

[JCS] log from info to debug in dispose

2014-05-28 Thread Romain Manni-Bucau

Hi

any objection to use debug level for first log message
in org.apache.commons.jcs.engine.control.CompositeCache#dispose(boolean)?

It prints something like:

mai 28, 2014 7:13:02 PM
org.apache.commons.jcs.engine.control.CompositeCache dispose
Infos: In DISPOSE, [javax.cache.expiry.ExpiryPolicyTest] fromRemote [false]
Region Name = javax.cache.expiry.ExpiryPolicyTest
HitCountRam = 0
HitCountAux = 0
---Memory Cache
List Size = 0
Map Size = 0
Put Count = 0
Hit Count = 0
Miss Count = 0

Worse case would it be possible to get an inline version?


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau

[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

2014-05-28 Thread Apache Continuum

Online report : 
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=31537&projectId=286

Build statistics:
  State: Failed
  Previous State: Failed
  Started at: Wed 28 May 2014 17:20:43 +
  Finished at: Wed 28 May 2014 17:24:36 +
  Total time: 3m 52s
  Build Trigger: Schedule
  Build Number: 1
  Exit code: 1
  Building machine hostname: continuum-vm
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_27"
  OpenJDK Runtime Environment (IcedTea6 1.12.6) 
(6b27-1.12.6-1ubuntu0.12.04.4)
  OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)

  Builder version :
  Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 
2013-02-19 13:51:28+)
  Maven home: /opt/apache-maven-3.0.5
  Java version: 1.6.0_27, vendor: Sun Microsystems Inc.
  Java home: /usr/lib/jvm/java-6-openjdk-amd64/jre
  Default locale: en_US, platform encoding: UTF-8
  OS name: "linux", version: "3.2.0-53-generic", arch: "amd64", family: 
"unix"


SCM Changes:

Changed: rmannibucau @ Wed 28 May 2014 17:06:12 +
Comment: using reentrant locks instead of old synchronized
Files changed:
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/LRUMapJCS.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractMemoryCache.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/logger
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/logger/LogHelper.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/LRUMap.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/SingleLinkedList.java
 ( 1598071 )

Changed: rmannibucau @ Wed 28 May 2014 17:16:31 +
Comment: adding jcache-fast.sh to test quickly jcache build and calling pending 
tasks before shutdown on JCache
Files changed:
  
/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java
 ( 1598074 )
  /commons/proper/jcs/trunk/jcache-fast.sh ( 1598074 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 3.0.5
Description: Group (shared) Maven 3 Build Definition (Java 1.6)


Test Summary:

Tests: 379
Failures: 4
Errors: 0
Success Rate: 98
Total time: 131.18602


Test Failures:


BasicRemoteCacheClientServerUnitTest
test1SinglePut :
  java.lang.AssertionError
  java.lang.AssertionError: Cache is alive expected: but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at 
org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test1SinglePut(BasicRemoteCacheClientServerUnitTest.java:118)


test2PutRemove :
  java.lang.AssertionError
  java.lang.AssertionError: Cache is alive expected: but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at 
org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test2PutRemove(BasicRemoteCacheClientServerUnitTest.java:168)


test3PutAndListen :
  java.lang.AssertionError
  java.lang.AssertionError: Cache is alive expected: but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(

[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons ()

2014-05-28 Thread Apache Continuum

Online report : 
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=31538&projectId=286

Build statistics:
  State: Failed
  Previous State: Failed
  Started at: Wed 28 May 2014 18:00:05 +
  Finished at: Wed 28 May 2014 18:04:43 +
  Total time: 4m 38s
  Build Trigger: Schedule
  Build Number: 1
  Exit code: 1
  Building machine hostname: continuum-vm
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.7.0_25"
  OpenJDK Runtime Environment (IcedTea 2.3.10) 
(7u25-2.3.10-1ubuntu0.12.04.2)
  OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)

  Builder version :
  Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 
2013-02-19 13:51:28+)
  Maven home: /opt/apache-maven-3.0.5
  Java version: 1.7.0_25, vendor: Oracle Corporation
  Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre
  Default locale: en_US, platform encoding: UTF-8
  OS name: "linux", version: "3.2.0-53-generic", arch: "amd64", family: 
"unix"


SCM Changes:

Changed: rmannibucau @ Wed 28 May 2014 17:06:12 +
Comment: using reentrant locks instead of old synchronized
Files changed:
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/LRUMapJCS.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractMemoryCache.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/logger
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/logger/LogHelper.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/LRUMap.java
 ( 1598071 )
  
/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/SingleLinkedList.java
 ( 1598071 )

Changed: rmannibucau @ Wed 28 May 2014 17:16:31 +
Comment: adding jcache-fast.sh to test quickly jcache build and calling pending 
tasks before shutdown on JCache
Files changed:
  
/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java
 ( 1598074 )
  /commons/proper/jcs/trunk/jcache-fast.sh ( 1598074 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean test   
Arguments: --batch-mode -Pjava-1.7 
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: DEFAULT_SCHEDULE
Profile Name: Maven 3.0.5 with Java 7
Description: 


Test Summary:

Tests: 379
Failures: 4
Errors: 0
Success Rate: 98
Total time: 178.65402


Test Failures:


BasicRemoteCacheClientServerUnitTest
test1SinglePut :
  java.lang.AssertionError
  java.lang.AssertionError: Cache is alive expected: but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at 
org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test1SinglePut(BasicRemoteCacheClientServerUnitTest.java:118)


test2PutRemove :
  java.lang.AssertionError
  java.lang.AssertionError: Cache is alive expected: but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at 
org.apache.commons.jcs.auxiliary.remote.server.BasicRemoteCacheClientServerUnitTest.test2PutRemove(BasicRemoteCacheClientServerUnitTest.java:168)


test3PutAndListen :
  java.lang.AssertionError
  java.lang.AssertionError: Cache is alive expected: but was:
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at 
org.apache.commons.jcs.auxiliary.re

Re: [VOTE] Release BeanUtils 1.9.2 based on RC1

2014-05-28 Thread Oliver Heger

Hi Gary,

Am 28.05.2014 01:33, schrieb Gary Gregory:
> How about adding FindBugs and PMD reports for the next go around?

agreed, this would be good. However, please keep in mind that
[beanutils] is currently in pure maintenance mode. I do what I think is
necessary and don't have the ambitions to polish the code base.

Oliver

> 
> Gary
> 
> 
> On Mon, May 26, 2014 at 3:39 PM, Oliver Heger
> wrote:
> 
>> This is a vote to release Commons BeanUtils 1.9.2 based on the first RC.
>> There was a fix related to a security issue which should now be made
>> available.
>>
>> BeanUtils 1.9.2 RC1 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/beanutils/ (svn
>> revision 5419)
>>
>>   Maven artifacts are here:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1032/
>>
>>   Details of changes since 1.9.1 are in the release notes:
>>
>> https://dist.apache.org/repos/dist/dev/commons/beanutils/RELEASE-NOTES.txt
>>
>> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/changes-report.html
>>
>>   The tag is here:
>>
>>
>> http://svn.apache.org/repos/asf/commons/proper/beanutils/tags/BEANUTILS_1_9_2_RC1/
>> (svn 1597453)
>>
>>   Site:
>> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/
>>   (note some *relative* links are broken and some new directories are
>>   not yet created - these will be OK once the site is deployed)
>>
>>   KEYS:
>>   http://www.apache.org/dist/commons/KEYS
>>
>> Note: There is a known issue with some tests related to memory leak
>> detection failing on some environments. This has already been the case
>> for the previous release; there were no changes in this area.
>>
>>   Please review the release candidate and vote.
>>   This vote will close no sooner that 72 hours from now, i.e. after 2000
>> GMT 29-May 2014
>>
>>   [ ] +1 Release these artifacts
>>   [ ] +0 OK, but...
>>   [ ] -0 OK, but really should fix...
>>   [ ] -1 I oppose this release because...
>>
>>   Thanks!
>>
>>   Oliver
>>
>> -
>> 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: [VOTE] Release BeanUtils 1.9.2 based on RC1

2014-05-28 Thread Gary Gregory

On Wed, May 28, 2014 at 3:58 PM, Oliver Heger
wrote:

> Hi Gary,
>
> Am 28.05.2014 01:33, schrieb Gary Gregory:
> > How about adding FindBugs and PMD reports for the next go around?
>
> agreed, this would be good. However, please keep in mind that
> [beanutils] is currently in pure maintenance mode. I do what I think is
> necessary and don't have the ambitions to polish the code base.
>

Sure, I understand how you feel, but each person can decide where to
contribute, this adds transparency to the component. No biggie, I just kind
of expect these reports to be around these days.

Gary


>
> Oliver
>
> >
> > Gary
> >
> >
> > On Mon, May 26, 2014 at 3:39 PM, Oliver Heger
> > wrote:
> >
> >> This is a vote to release Commons BeanUtils 1.9.2 based on the first RC.
> >> There was a fix related to a security issue which should now be made
> >> available.
> >>
> >> BeanUtils 1.9.2 RC1 is available for review here:
> >> https://dist.apache.org/repos/dist/dev/commons/beanutils/ (svn
> >> revision 5419)
> >>
> >>   Maven artifacts are here:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1032/
> >>
> >>   Details of changes since 1.9.1 are in the release notes:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/commons/beanutils/RELEASE-NOTES.txt
> >>
> >>
> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/changes-report.html
> >>
> >>   The tag is here:
> >>
> >>
> >>
> http://svn.apache.org/repos/asf/commons/proper/beanutils/tags/BEANUTILS_1_9_2_RC1/
> >> (svn 1597453)
> >>
> >>   Site:
> >> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/
> >>   (note some *relative* links are broken and some new directories are
> >>   not yet created - these will be OK once the site is deployed)
> >>
> >>   KEYS:
> >>   http://www.apache.org/dist/commons/KEYS
> >>
> >> Note: There is a known issue with some tests related to memory leak
> >> detection failing on some environments. This has already been the case
> >> for the previous release; there were no changes in this area.
> >>
> >>   Please review the release candidate and vote.
> >>   This vote will close no sooner that 72 hours from now, i.e. after 2000
> >> GMT 29-May 2014
> >>
> >>   [ ] +1 Release these artifacts
> >>   [ ] +0 OK, but...
> >>   [ ] -0 OK, but really should fix...
> >>   [ ] -1 I oppose this release because...
> >>
> >>   Thanks!
> >>
> >>   Oliver
> >>
> >> -
> >> 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
>
>


-- 
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 BeanUtils 1.9.2 based on RC1

2014-05-28 Thread Gary Gregory

+1.

Builds OK on:

Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
08:51:28-0500)
Maven home: C:\Java\apache-maven-3.0.5
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_55\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Gary


On Mon, May 26, 2014 at 3:39 PM, Oliver Heger
wrote:

> This is a vote to release Commons BeanUtils 1.9.2 based on the first RC.
> There was a fix related to a security issue which should now be made
> available.
>
> BeanUtils 1.9.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/beanutils/ (svn
> revision 5419)
>
>   Maven artifacts are here:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1032/
>
>   Details of changes since 1.9.1 are in the release notes:
>
> https://dist.apache.org/repos/dist/dev/commons/beanutils/RELEASE-NOTES.txt
>
> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/changes-report.html
>
>   The tag is here:
>
>
> http://svn.apache.org/repos/asf/commons/proper/beanutils/tags/BEANUTILS_1_9_2_RC1/
> (svn 1597453)
>
>   Site:
> http://people.apache.org/~oheger/beanutils-1.9.2-rc1/
>   (note some *relative* links are broken and some new directories are
>   not yet created - these will be OK once the site is deployed)
>
>   KEYS:
>   http://www.apache.org/dist/commons/KEYS
>
> Note: There is a known issue with some tests related to memory leak
> detection failing on some environments. This has already been the case
> for the previous release; there were no changes in this area.
>
>   Please review the release candidate and vote.
>   This vote will close no sooner that 72 hours from now, i.e. after 2000
> GMT 29-May 2014
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>
>   Oliver
>
> -
> 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

[beanutils] 1.8.4 issues in JIRA

2014-05-28 Thread Emmanuel Bourg

Hi,

JIRA has several bugs marked as fixed in beanutils 1.8.4 but this
version was never released. Is it correct to assume they were fixed in
1.9.0?

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310460&version=12314869

Emmanuel Bourg

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

Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/

2014-05-28 Thread sebb

On 28 May 2014 18:06,   wrote:
> Author: rmannibucau
> Date: Wed May 28 17:06:12 2014
> New Revision: 1598071
>
> URL: http://svn.apache.org/r1598071
> Log:
> using reentrant locks instead of old synchronized

-1

This commit mixes two completely different changes:
- re-entrant locks
- addition of LogHelper

I think the LogHelper class is a bad idea. It is also not thread-safe.
If the cache is enabled, then it is not possible to change the logging
level during a run.

> Added:
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/logger/
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/logger/LogHelper.java
> Modified:
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/LRUMapJCS.java
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractMemoryCache.java
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/LRUMap.java
> 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/utils/struct/SingleLinkedList.java
>
> Modified: 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/LRUMapJCS.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/LRUMapJCS.java?rev=1598071&r1=1598070&r2=1598071&view=diff
> ==
> --- 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/LRUMapJCS.java
>  (original)
> +++ 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/disk/LRUMapJCS.java
>  Wed May 28 17:06:12 2014
> @@ -19,6 +19,7 @@ package org.apache.commons.jcs.auxiliary
>   * under the License.
>   */
>
> +import org.apache.commons.jcs.utils.logger.LogHelper;
>  import org.apache.commons.jcs.utils.struct.LRUMap;
>  import org.apache.commons.logging.Log;
>  import org.apache.commons.logging.LogFactory;
> @@ -35,6 +36,7 @@ public class LRUMapJCS
>
>  /** The logger */
>  private static final Log log = LogFactory.getLog( LRUMapJCS.class );
> +private static final LogHelper LOG_HELPER = new LogHelper(log);
>
>  /**
>   * This creates an unbounded version.
> @@ -69,7 +71,7 @@ public class LRUMapJCS
>  @Override
>  protected void processRemovedLRU(K key, V value)
>  {
> -if ( log.isDebugEnabled() )
> +if ( LOG_HELPER.isDebugEnabled() )
>  {
>  log.debug( "Removing key [" + key + "] from key store, value [" 
> + value + "]" );
>  log.debug( "Key store size [" + this.size() + "]" );
>
> Modified: 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java?rev=1598071&r1=1598070&r2=1598071&view=diff
> ==
> --- 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java
>  (original)
> +++ 
> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java
>  Wed May 28 17:06:12 2014
> @@ -46,6 +46,7 @@ import org.apache.commons.jcs.engine.sta
>  import org.apache.commons.jcs.engine.stats.behavior.ICacheStats;
>  import org.apache.commons.jcs.engine.stats.behavior.IStatElement;
>  import org.apache.commons.jcs.engine.stats.behavior.IStats;
> +import org.apache.commons.jcs.utils.logger.LogHelper;
>  import org.apache.commons.logging.Log;
>  import org.apache.commons.logging.LogFactory;
>
> @@ -70,6 +71,7 @@ public class CompositeCache
>  {
>  /** log instance */
>  private static final Log log = LogFactory.getLog( CompositeCache.class );
> +private static final LogHelper LOG_HELPER = new LogHelper(log);
>
>  /**
>   * EventQueue for handling element events. Lazy initialized. One for 
> each region. To be more efficient, the manager
> @@ -228,7 +230,7 @@ public class CompositeCache
>  throw new IllegalArgumentException( "key cannot be a GroupId " + 
> " for a put operation" );
>  }
>
> -if ( log.isDebugEnabled() )
> +if ( LOG_HELPER.isDebugEnabled() )
>  {
>  log.debug( "Updating memory cache " + cacheElement.getKey() );
>  }
> @@ -271,7 +273,7 @@ public class CompositeCache
>

Re: svn commit: r1594073 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/remote/server/ engine/memory/ engine/memory/util/

2014-05-28 Thread Phil Steitz

On 5/28/14, 4:47 AM, Romain Manni-Bucau wrote:
> I'm convinced of it (why the comment was this way). I'll try to rework it
> this week based on the LockFactory we spoke about in another thread.

Great.  Would would be good to explain when implementing these
changes is:

0) what sequences of operations were performed atomically in sync
blocks before
1) why the atomicity is not necessary, if the sycn protection
(whether using synchronized blocks or explicit locks) is removed
2) what invariants JCS maintained before the changes and after

Then people can weigh in on whether the changes are OK, based on
known use cases and comfort level changing contracts (if
necessary).  Ideal is to lay this out before committing changes so
you don't have to deal with -1's; but we are CTR so OK to commit
first and then explain after if that is easier.  It is also better
if you can break large commits up if possible and break changes into
separate JIRAs where possible.

Phil
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-05-28 2:19 GMT+02:00 Phil Steitz :
>
>> On 5/27/14, 11:17 AM, Benedikt Ritter wrote:
>>> Send from my mobile device
>>>
 Am 13.05.2014 um 20:53 schrieb Phil Steitz :

> On 5/12/14, 12:46 PM, rmannibu...@apache.org wrote:
> Author: rmannibucau
> Date: Mon May 12 19:46:08 2014
> New Revision: 1594073
>
> URL: http://svn.apache.org/r1594073
> Log:
> removing a bunch of synchronized thanks to ConcurrentHashMap - still
>> removeAll to review since it can be not that good but using any synch would
>> make it slower and not scalable
> Modified:
>
>>  
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java
>>  
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
>>  
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/util/MemoryElementDescriptor.java
> Modified:
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java
> URL:
>> http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java?rev=1594073&r1=1594072&r2=1594073&view=diff
>> ==
> ---
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java
>> (original)
> +++
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/auxiliary/remote/server/RemoteCacheServerFactory.java
>> Mon May 12 19:46:08 2014
> @@ -81,7 +81,7 @@ public class RemoteCacheServerFactory
>  * @return Returns the remoteCacheServer.
>  */
> @SuppressWarnings("unchecked") // Need cast to specific
>> RemoteCacheServer
> -public static 
>> RemoteCacheServer getRemoteCacheServer()
> +public static  RemoteCacheServer
>> getRemoteCacheServer()
> {
> return (RemoteCacheServer)remoteCacheServer;
> }
>
> Modified:
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
> URL:
>> http://svn.apache.org/viewvc/commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java?rev=1594073&r1=1594072&r2=1594073&view=diff
>> ==
> ---
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
>> (original)
> +++
>> commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/memory/AbstractDoubleLinkedListMemoryCache.java
>> Mon May 12 19:46:08 2014
> @@ -86,8 +86,11 @@ public abstract class AbstractDoubleLink
>
> /**
>  * This is called by super initialize.
> + *
> + * NOTE: should return a thread safe map
> + *
>  * 
> - * @return new Hashtable()
> + * @return new ConcurrentHashMap()
>  */
> @Override
> public Map> createMap()
> @@ -109,19 +112,15 @@ public abstract class AbstractDoubleLink
> {
> putCnt++;
>
> -synchronized ( this )
 I am not really familiar with this code, so this could be needless
 concern; but removing this synch makes the adjustListForUpdate no
 longer atomic with the put below.  Is this OK?
>>> Sorry, I seem to have missed the answer to this question. Was it okay to

Re: [VOTE] Release BeanUtils 1.9.2 based on RC1

Re: [VOTE] Release BeanUtils 1.9.2 based on RC1

Re: svn commit: r1594073 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/remote/server/ engine/memory/ engine/memory/util/

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

Re: [jcs] Ceanup and reorganize the project, was:Re: [VETO] Re: [jcs] What's next?

[JCS] log from info to debug in dispose

[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons (Group (shared) Maven 3 Build Definition (Java 1.6))

[continuum] BUILD FAILURE: Apache Commons JCS - Apache Commons ()

Re: [VOTE] Release BeanUtils 1.9.2 based on RC1

Re: [VOTE] Release BeanUtils 1.9.2 based on RC1

Re: [VOTE] Release BeanUtils 1.9.2 based on RC1

[beanutils] 1.8.4 issues in JIRA

Re: svn commit: r1598071 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/disk/ engine/control/ engine/memory/ utils/logger/ utils/struct/

Re: svn commit: r1594073 - in /commons/proper/jcs/trunk/commons-jcs-core/src/main/java/org/apache/commons/jcs: auxiliary/remote/server/ engine/memory/ engine/memory/util/

14 matches

Site Navigation

Mail list logo

Footer information