On 24/07/2012 08:42, Liviu Tudor wrote: > Phil & others who have been in touch with [pool], > > A follow up to this: I'm trying to log this in JIRA and submit a patch but > I've come across the following problem: > > 1/ The mechanism I am referring to had pool-1.6.0 in mind, however, I > can't find in SVN the branch for 1.6? There are release branches going up > to 1.5 but no 1.6? Can you point me in the right direction so I can create > the patch in the right branch?
Pool 2.x: http://svn.apache.org/repos/asf/commons/proper/pool/trunk/ Pool 1.6: http://svn.apache.org/repos/asf/commons/proper/pool/branches/POOL_1_X/ Pool 1.5: http://svn.apache.org/repos/asf/commons/proper/pool/branches/1_5_RELEASE/ In theory pool 1.5.x + conversion to generics = pool 1.6.x Pool 2.x is a complete re-write of the pooling mechanism. > 2/ Since we've moved now to pool2, I would like to apply something similar > for [pool2], however, looking at the code, I see we now have a > > List<K> getKeys(); > > Due to the Mbean interface we're implementing. This looks similar to my > idea of returning a Set<K> for the keys -- since the order of the keys of > the cache is not important I thought. Looking at the code it turns out > indeed the order is not important, so List is not justified and Set could > have done it just fine. So am I ok to change the Mbean and the class to > actually use a Set rather than a List? No. Order is important for eviction. Internally it has to be a List. Externally, the keys could be returned as a Set or a List. I don't have any strong feelings. Regardless, we should more clearly (there is a comment already) document the requirement for ordering of keys for eviction somewhere in the code since it doesn't appear to be clear enough. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org