Hi Matt!! :) nope, the [pool] component is totally self-contained, it doesn't have any dependency. Have a nice day, Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Oct 12, 2010 at 4:54 PM, Matt Benson <gudnabr...@gmail.com> wrote: > Looks like their javadoc is a little off, recommending new > MetaDataKey(Role.class) { } when I believe they meant new MetaDataKey<Role>() > { } . This resonates with the optionality I did for the type parameter in > the proxy2-stub module's StubConfigurer class: if the implementation has the > variable assigned as by an anonymous inner class declaration, no need to pass > the class reference explicitly. This does necessitate some generics-smart > code; does [pool] depend on [lang]? lang3's TypeUtils takes care of this > nicely. > > -Matt > > > On Oct 12, 2010, at 8:38 AM, James Carman wrote: > >> If you're going to do that, I'd recommend doing something similar to >> what the Wicket folks did: >> >> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/MetaDataKey.html >> >> http://wicket.apache.org/apidocs/1.4/org/apache/wicket/Application.html#getMetaData%28org.apache.wicket.MetaDataKey%29 >> >> This way, the key has type information "baked in." >> >> On Tue, Oct 12, 2010 at 9:29 AM, Brent Worden <brent.wor...@gmail.com> wrote: >>> The javadoc on KeyedObjectPool states 'A keyed pool pools instances of >>> multiple types.' However, the new parametrization on KeyedObjectPool allows >>> for only a single instance type. >>> >>> To allow for pooling multiple typed instances, should the instance type >>> parameter be removed from the interface declaration and placed on the >>> relevant method declarations? In other words, replace: >>> >>> public interface KeyedObjectPool<K,V> { >>> ... >>> } >>> >>> with: >>> >>> public interface KeyedObjectPool<K> { >>> >>> <V> V borrowObject(K key); >>> >>> <V> void invalidateObject(K key, V obj); >>> >>> <V> void returnObject(K key, V obj); >>> ... >>> } >>> >>> Thoughts? >>> >>> Brent. >>> >>> >>> --------------------------------------------------------------------- >>> 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 >> > > > --------------------------------------------------------------------- > 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
