To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp has an issue affecting its community integration.
This issue
On 13 October 2010 01:15, Paul Benedict wrote:
> The whole convention comes from java.util where there are
> "elements" of a collection.
Yes, I know.
> I don't like to mix things. I think type T
> would be find everywhere unless you have multiple types and need a
> memorable letter.
As far as
On Oct 12, 2010, at 4:42 PM, Jörg Schaible wrote:
> Gary Gregory wrote:
>
>> I too would like to be able to tweak the size of the pool at runtime.
>>
>> Gary
>>
>> On Oct 12, 2010, at 13:19, "James Carman"
>> wrote:
>>
>>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>>> wrote:
The whole convention comes from java.util where there are
"elements" of a collection. I don't like to mix things. I think type T
would be find everywhere unless you have multiple types and need a
memorable letter.
On Tue, Oct 12, 2010 at 6:21 PM, sebb wrote:
> CursorableLinkedList is based on th
> -Original Message-
> From: Gary Gregory
> Sent: Tuesday, October 12, 2010 17:08
> To: dev@commons.apache.org; 'joerg.schai...@gmx.de'
> Subject: RE: [pool] runtime re-configuration
>
> > -Original Message-
> > From: Jörg Schaible [mailto:joerg.schai...@gmx.de]
> > Sent: Tuesday,
> -Original Message-
> From: Jörg Schaible [mailto:joerg.schai...@gmx.de]
> Sent: Tuesday, October 12, 2010 16:42
> To: dev@commons.apache.org
> Subject: Re: [pool] runtime re-configuration
>
> Gary Gregory wrote:
>
> > I too would like to be able to tweak the size of the pool at runtime.
That was my point. The break in binary compatibility makes moot the
previous discussion about the appropriateness of [io] moving to 2.0.
On 10/12/10, Gary Gregory wrote:
> I do not think that we need to worry about binary compatibility because the
> classes are @since 2.0.
>
> Gary
>
> On Oct 12
Gary Gregory wrote:
> I too would like to be able to tweak the size of the pool at runtime.
>
> Gary
>
> On Oct 12, 2010, at 13:19, "James Carman"
> wrote:
>
>> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
>> wrote:
>>> Hi Phil! :)
>>> honestly I didn't understand which are the use cases
While we are on the topic of CursorableLinkedList, I wonder if j.u.c provides a
data structure that we could use and avoid maintaining CursorableLinkedList?
Gary
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, October 12, 2010 16:22
> To: Commons Developers L
CursorableLinkedList is based on the type T, and removeFirst() returns
T, yet getFirst() returns Object.
Also, toArray() returns Object[] or E[].
Not sure I follow why there is this mixture?
-
To unsubscribe, e-mail: dev-unsubsc
I do not think that we need to worry about binary compatibility because the
classes are @since 2.0.
Gary
On Oct 12, 2010, at 14:38, "Matt Benson" wrote:
> On the bright side, having given in to the wishes of those who wanted this
> naming change makes the question of whether there is suffici
I too would like to be able to tweak the size of the pool at runtime.
Gary
On Oct 12, 2010, at 13:19, "James Carman" wrote:
> On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
> wrote:
>> Hi Phil! :)
>> honestly I didn't understand which are the use cases when a pool needs
>> to be reconfigure
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
On the bright side, having given in to the wishes of those who wanted this
naming change makes the question of whether there is sufficient reason for a
major version bump, as the API is no longer binary-compatible, right?
On Oct 12, 2010, at 2:27 PM, nia...@apache.org wrote:
> Author: niallp
>
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=1077&projectId=98
Build statistics:
State: Failed
Previous State: Failed
Started at: Tue 12 Oct 2010 21:21:35 +
Finished at: Tue 12 Oct 2010 21:24:16 +
Total time: 2m 41s
Build Trigger: Schedule
B
On 12 October 2010 21:23, wrote:
> Author: simonetripodi
> Date: Tue Oct 12 20:23:02 2010
> New Revision: 1021913
>
> URL: http://svn.apache.org/viewvc?rev=1021913&view=rev
> Log:
> removed test that explicitly required a null factory
> fixed broken tests
>
Sorry, got distracted and forgot to fi
Good point James, thanks for the feedback! I suppose that's the reason
why previous maintainers let the fields protected to access them
directly, that will be replaced by setters/getters methods.
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 10:18
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=1075&projectId=98
Build statistics:
State: Failed
Previous State: Ok
Started at: Tue 12 Oct 2010 20:23:51 +
Finished at: Tue 12 Oct 2010 20:24:07 +
Total time: 15s
Build Trigger: Schedule
Build Nu
On Tue, Oct 12, 2010 at 20:43, Gary Gregory
wrote:
>> -Original Message-
>> From: mfncoo...@gmail.com [mailto:mfncoo...@gmail.com] On Behalf Of Martin
>> Cooper
>> Sent: Monday, October 11, 2010 19:42
>> To: Commons Developers List
>> Subject: Re: Weird class names [WAS RE: [VOTE] Release
On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
wrote:
> Hi Phil! :)
> honestly I didn't understand which are the use cases when a pool needs
> to be reconfigured, that's why I've always used the pool in "configure
> and use" modality and Seb's suggestion sounded good to me. OTOH I
> didn't modif
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
Agreed, I already started but stopped to have dinner :P
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 9:25 PM, Gary Gregory
wrote:
>> -Original Message-
>> From: sebb [mailto:seb...@gmail.com]
>> Sent: Tuesday, October 12, 2010 12:15
>> To
This vote is cancelled :(
Thanks for reviewing/voting
Niall
On Sun, Oct 10, 2010 at 3:59 PM, Niall Pemberton
wrote:
> I have prepared Commons IO 2.0 RC4. The main change since RC4 was to
> fix the Ant build
>
> The RC3 changes were improvements to some tests which were causing
> intermittent fa
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, October 12, 2010 12:15
> To: Commons Developers List
> Subject: Re: [pool] can the factory field ever usefully be null?
>
> On 12 October 2010 20:02, Gary Gregory wrote:
> >> -Original Message-
> >> From:
On 10/12/10 3:14 PM, sebb wrote:
On 12 October 2010 20:02, Gary Gregory wrote:
-Original Message-
From: sebb [mailto:seb...@gmail.com]
Sent: Tuesday, October 12, 2010 11:28
To: Commons Developers List
Subject: [pool] can the factory field ever usefully be null?
Now that the setFactory(
On 12 October 2010 20:02, Gary Gregory wrote:
>> -Original Message-
>> From: sebb [mailto:seb...@gmail.com]
>> Sent: Tuesday, October 12, 2010 11:28
>> To: Commons Developers List
>> Subject: [pool] can the factory field ever usefully be null?
>>
>> Now that the setFactory() methods have b
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, October 12, 2010 11:28
> To: Commons Developers List
> Subject: [pool] can the factory field ever usefully be null?
>
> Now that the setFactory() methods have been removed, and the factories
> made immutable, does
> -Original Message-
> From: mfncoo...@gmail.com [mailto:mfncoo...@gmail.com] On Behalf Of Martin
> Cooper
> Sent: Monday, October 11, 2010 19:42
> To: Commons Developers List
> Subject: Re: Weird class names [WAS RE: [VOTE] Release Commons IO 2.0 based on
> RC3]
>
> On Mon, Oct 11, 2010 a
Now that the setFactory() methods have been removed, and the factories
made immutable, does it still make sense to ever allow a null factory?
Some places still check for null, some assume non-null.
There are also some ctors which set the factory to null.
Seems to me that the factory field needs t
Yes
On Oct 12, 2010, at 12:17 PM, Simone Tripodi wrote:
> Hi Phil,
> OK that's clear, according to this policy, just to keep things
> consistent, also *.Config properties should be accessed only by
> getters/setters, how does it sound for you?
> Simo
>
> http://people.apache.org/~simonetripod
cool, I read the commit and agree!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 7:16 PM, Gary Gregory
wrote:
> I see that Java 5 enhance for loop are in used yet. I thought I'd fix that
> up. In progress...
>
> Gary
>
I see that Java 5 enhance for loop are in used yet. I thought I'd fix that up.
In progress...
Gary
+1 also on syncronizing the methods, I can take this task in charge.
Thanks all,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 6:46 PM, Gary Gregory
wrote:
>> -Original Message-
>> From: sebb [mailto:seb...@gmail.com]
>> Sent: Tuesday, Oct
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Tuesday, October 12, 2010 09:39
> To: Commons Developers List
> Subject: Re: [pool] runtime re-configuration
>
> On 12 October 2010 17:13, Phil Steitz wrote:
> > On 10/12/10 11:26 AM, sebb wrote:
> >>
> >> On 12 October 2
On 12 October 2010 17:13, Phil Steitz wrote:
> On 10/12/10 11:26 AM, sebb wrote:
>>
>> On 12 October 2010 16:03, Phil Steitz wrote:
>>>
>>> On 10/12/10 7:32 AM, Simone Tripodi wrote:
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows mo
Hi Phil,
OK that's clear, according to this policy, just to keep things
consistent, also *.Config properties should be accessed only by
getters/setters, how does it sound for you?
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 6:13 PM, Phil Steitz
On 10/12/10 11:26 AM, sebb wrote:
On 12 October 2010 16:03, Phil Steitz wrote:
On 10/12/10 7:32 AM, Simone Tripodi wrote:
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows more than me.
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www
> -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, James Carman wrote:
> >> Is
Just one note, Phil:
On Tue, Oct 12, 2010 at 5:39 PM, Phil Steitz wrote:
> how much time we collectively spend fussing with the build b) how hard it is
> for new RMs to create and deploy RCs
Having been RM on several occasions and in various projects, I never
found doing a release easier than
I don't like Maven - I prefer Ant. My co-developer for the Commons
Convert project said that the use of Maven is almost a deal breaker for him.
Please keep Ant build file support in Commons.
-Adrian
On 10/12/2010 8:39 AM, Phil Steitz wrote:
)
Why would anyone not use maven!!! ;)
http://s
Hi,
I have two questions.
I was going through the SimplexTableau.java code, tried to understand every
line
of it. In the dropPhase1Objective() method I was puzzled a little bit, maybe
you
can explain.
You are dropping positive cost non-artificial variables, which means that some
original dec
)
Why would anyone not use maven!!! ;)
http://s.apache.org/m3blog
...joking aside though - if people are prepared to maintain the ant
builds (and I am for the components I work on) then no need to get rid
of them.
OK, I have now been baited ;) I was going to post the response
below
On 12 October 2010 16:03, Phil Steitz wrote:
> On 10/12/10 7:32 AM, Simone Tripodi wrote:
>>
>> Hi Seb,
>> I totally agree, I'm for this solution, BTW I'll wait the Phil's
>> opinion that knows more than me.
>> Thanks!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org
Hi Phil! :)
honestly I didn't understand which are the use cases when a pool needs
to be reconfigured, that's why I've always used the pool in "configure
and use" modality and Seb's suggestion sounded good to me. OTOH I
didn't modify any single code line before hearing your thoughts since
you know
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
On 10/12/10 7:32 AM, Simone Tripodi wrote:
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows more than me.
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 12:50 PM, sebb wrote:
On 12 October 2010
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
On 10/12/10 7:23 AM, Mark Thomas wrote:
On 12/10/2010 10:32, Simone Tripodi wrote:
Hi all,
following Phil's suggestion to point out candidates for deprecation /
removal, I notice that both GenericObjectPool and
GenericObjectPoolFactory share WHEN_EXHAUSTED_* properties of type
byte to discrimina
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
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
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
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
Hi James,
thanks for the feedback
Guys, please review r1021756, I introduced a WhenExhaustedAction
enumeration that's shared between all
Generic(Keyed)?ObjectPool(Factory)? components.
I also removed the useless
TestGenericObjectPool.testInvalidWhenExhaustedAction() since
WhenExhaustedAction i
+1 to enums
On Tue, Oct 12, 2010 at 7:34 AM, Simone Tripodi
wrote:
> Hi Mark,
> thank a lot for your feedback! I agree with your POV, since we're
> using Java1.5 we should take advantage of the whole provided features
> :)
> Thanks!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www
Hi Mark,
thank a lot for your feedback! I agree with your POV, since we're
using Java1.5 we should take advantage of the whole provided features
:)
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 1:23 PM, Mark Thomas wrote:
> On 12/10/2010 1
Hi Seb,
I totally agree, I'm for this solution, BTW I'll wait the Phil's
opinion that knows more than me.
Thanks!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 12:50 PM, sebb wrote:
> On 12 October 2010 10:20, Simone Tripodi wrote:
>> Hi all guys
Hi Seb,
thanks for your feedbacks, I'm more for changing the method signature
rather than loose the power of generics, but that's just my opinion.
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Oct 12, 2010 at 12:44 PM, sebb wrote:
> On 12 October
On 12/10/2010 10:32, Simone Tripodi wrote:
> Hi all,
> following Phil's suggestion to point out candidates for deprecation /
> removal, I notice that both GenericObjectPool and
> GenericObjectPoolFactory share WHEN_EXHAUSTED_* properties of type
> byte to discriminate the action to perform when the
On 12 October 2010 10:20, Simone Tripodi wrote:
> Hi all guys,
> while fixing the deprecated properties in classes like
> StackKeyedObjectPool[1], I noticed this class instance was
> re-configured during the test[2] (see line 126); is the
> "reconfigure-in-runtime" a pool feature we want? I'm aski
On 12 October 2010 11:19, Jörg Schaible wrote:
> sebb wrote:
>
>> On 12 October 2010 10:06, Jörg Schaible wrote:
>>> Hi Simone,
>>>
>>> Simone Tripodi wrote:
>>>
Hi all mates,
please help me, even if I temporary fixed the compiler issue, I didn't
understand why
void pref
sebb wrote:
> On 12 October 2010 10:06, Jörg Schaible wrote:
>> Hi Simone,
>>
>> Simone Tripodi wrote:
>>
>>> Hi all mates,
>>> please help me, even if I temporary fixed the compiler issue, I didn't
>>> understand why
>>>
>>> void prefill(final KeyedObjectPool keyedPool, final K
>>> key, final i
On 12 October 2010 10:06, Jörg Schaible wrote:
> Hi Simone,
>
> Simone Tripodi wrote:
>
>> Hi all mates,
>> please help me, even if I temporary fixed the compiler issue, I didn't
>> understand why
>>
>> void prefill(final KeyedObjectPool keyedPool, final K
>> key, final int count) throws Except
Hi all,
following Phil's suggestion to point out candidates for deprecation /
removal, I notice that both GenericObjectPool and
GenericObjectPoolFactory share WHEN_EXHAUSTED_* properties of type
byte to discriminate the action to perform when the pool is exhausted.
Do you agree on replacing byte wi
Hi all guys,
while fixing the deprecated properties in classes like
StackKeyedObjectPool[1], I noticed this class instance was
re-configured during the test[2] (see line 126); is the
"reconfigure-in-runtime" a pool feature we want? I'm asking because
I've never experienced the pool reconfiguration
Hi Simone,
Simone Tripodi wrote:
> Hi all mates,
> please help me, even if I temporary fixed the compiler issue, I didn't
> understand why
>
>void prefill(final KeyedObjectPool keyedPool, final K
> key, final int count) throws Exception, IllegalArgumentException
>void prefill(final Keyed
Hi all mates,
please help me, even if I temporary fixed the compiler issue, I didn't
understand why
void prefill(final KeyedObjectPool keyedPool, final K
key, final int count) throws Exception, IllegalArgumentException
void prefill(final KeyedObjectPool keyedPool, final
Collection keys, fina
72 matches
Mail list logo
