On Oct 12, 2010, at 3:14 PM, James Carman wrote:
> You don't need generic-smart code for what they do in Wicket. Here's
> the signature of the "get" method:
>
> public final T getMetaData(MetaDataKey key)
>
> So, when you're using an object of type MetaDataKey you can
> only set/get string ob
You don't need generic-smart code for what they do in Wicket. Here's
the signature of the "get" method:
public final T getMetaData(MetaDataKey key)
So, when you're using an object of type MetaDataKey you can
only set/get string objects using it.
On Tue, Oct 12, 2010 at 10:54 AM, Matt Benson w
> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com]
> Sent: Tuesday, October 12, 2010 08:17
> To: Commons Developers List
> Subject: Re: [POOL] generics on KeyedObjectPool
>
> On 10/12/10 10:11 AM, Mark Thomas wrote:
> > On 12/10/2010 15:03,
On 10/12/10 10:11 AM, Mark Thomas wrote:
On 12/10/2010 15:03, James Carman wrote:
Is it really realistic to think that a pool would support multiple
object types? I've never really seen that in practice, but I guess it
could happen. Just seems weird to me.
+1. I'm having a hard time coming u
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 wrote:
> Looks like their javadoc is a little off, recommending
Looks like their javadoc is a little off, recommending new
MetaDataKey(Role.class) { } when I believe they meant new MetaDataKey() {
} . 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 as
I'm good with a pool consisting of one type of object
On Tue, Oct 12, 2010 at 10:11 AM, Mark Thomas wrote:
> On 12/10/2010 15:03, James Carman wrote:
>> Is it really realistic to think that a pool would support multiple
>> object types? I've never really seen that in practice, but I guess it
>>
Hi James, Mark,
Being honest, I've never experienced using the keyed pool to store
multiple types too, I've always used different instances to store
multiple types to avoid get confused, otherwise it would be very easy
- at least to me - get trapped in a Tower of Babel.
I agree with you on keeping
On 12/10/2010 15:03, James Carman wrote:
> Is it really realistic to think that a pool would support multiple
> object types? I've never really seen that in practice, but I guess it
> could happen. Just seems weird to me.
+1. I'm having a hard time coming up with a use case where those objects
w
Is it really realistic to think that a pool would support multiple
object types? I've never really seen that in practice, but I guess it
could happen. Just seems weird to me.
On Tue, Oct 12, 2010 at 9:49 AM, Simone Tripodi
wrote:
> Hi Brent!
> sounds reasonably good, the only worry I've on it
Hi Brent!
sounds reasonably good, the only worry I've on it is about the method
V borrowObject(K key);
because I don't know the type of V; speaking in therms of examples:
new MyKeyedObjectPoolImpl().borrowObject("one") = ???
So the APIs have to be improved following the Jame's suggesti
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 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
13 matches
Mail list logo
