I vote:
>> [X] +1 Yes lets sponsor it
>> [ ] -1 No because...
>>
>>
>> [X] +1 Use the Commons mailing lists
>> [ ] -1 Bad idea because...
>>
>>
Tommaso
Phil Steitz wrote:
> sebb wrote:
>> PoolingConnection$PStmtKey.PoolingConnection$PStmtKey._resultSetType
>> could be null and is guaranteed to be dereferenced in
>> org.apache.commons.dbcp.PoolingConnection.makeObject(Object)
>> This looks like a bug; just check for null in the second condition?
>
Niall Pemberton schrieb:
[X] +1 Yes lets sponsor it
[ ] -1 No because...
[X] +1 Use the Commons mailing lists
[ ] -1 Bad idea because...
Oliver
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional co
Hi Donald,
Excellent! I am interested in being an initial committer.
-Jeremy
(OpenJPA Committer and PMC Member)
On Wed, Nov 18, 2009 at 3:02 PM, Donald Woods wrote:
> We have an initial draft proposal to create a JSR-303 Bean Validation
> implementation at Apache as an incubator podling.
>
>
Hi, Commons Developers,
There's a minor regression in Codec-1.4 that causes two extra white
space characters to appear at the very end of the Base64 output when
using the instance encode() method instead of the static one:
https://issues.apache.org/jira/browse/CODEC-89
This seems to be causing
The JUnit tests produce a lot of output, even if the tests are successful.
Is there really any need to print stack traces in the following method?
TestSharedPoolDataSource.PoolTest.run()
I propose to comment them out.
Similarly, the test case TestManual.testLogWriter() generates a lot of output
On Wed, Nov 18, 2009 at 3:34 PM, Niall Pemberton
wrote:
>
> [X] +1 Yes lets sponsor it
> [ ] -1 No because...
>
>
> In order to make it easier for commons to *observe* the incubation
> effort does anyone object to discussion taking place on d...@commons
> rather than a separate list and commits
On 22/11/2009, henrib wrote:
>
> Any other opinion ?
> Sebb, Rahul, what's your take ?
I've not used the JEXL API at all, except via BSF/JSR-223 (which have
unchanged APIs).
So I can't really comment on whether the JEXL API changes are likely
to cause problems or not.
Seems to me it would be
On Sun, Nov 22, 2009 at 12:40 PM, henrib wrote:
>
> Any other opinion ?
> Sebb, Rahul, what's your take ?
I agree with your comments about compatibility for casual users. In
effect, some Commons components (those we've sometimes characterized
as ones with narrow deep APIs, such as JEXL) almost h
>>> Sure, but how many users have that requirement? More than 1%?
>>
>> Even if it is 1%, it's worth considering. I am really not comfortable
>> with project addressing only the 80% more frequent cases. Minority
>> should never be neglected. It's clearly a philosophical and personal choice.
You ju
On Mon, Nov 23, 2009 at 9:58 AM, Luc Maisonobe wrote:
> Torsten Curdt a écrit :
>>> We use some commons projects in one of our commercial products that
>>> uses in-browser applets. Size is very important for some of our
>>> customers who have clients connecting in from geographically remote
>>> ou
Torsten Curdt a écrit :
>> We use some commons projects in one of our commercial products that
>> uses in-browser applets. Size is very important for some of our
>> customers who have clients connecting in from geographically remote
>> outstations over links with about as much bandwidth as a piece
On Mon, Nov 23, 2009 at 7:24 AM, Phil Steitz wrote:
> As
> Torsten pointed out, the difficulty managing "multi-releases" is
> also not to be underestimated. IMO we do not do as good a job as we
> should releasing often and early in Commons and I would be hesitant
> to make a change that made that
On 23/11/2009, Phil Steitz wrote:
> Phil Steitz wrote:
> > s...@apache.org wrote:
> >> Author: sebb
> >> Date: Mon Nov 23 16:18:50 2009
> >> New Revision: 883394
> >>
> >> URL: http://svn.apache.org/viewvc?rev=883394&view=rev
> >> Log:
> >> Boolean.valueOf() is better than new Boolean()
>
Phil Steitz wrote:
> s...@apache.org wrote:
>> Author: sebb
>> Date: Mon Nov 23 16:18:50 2009
>> New Revision: 883394
>>
>> URL: http://svn.apache.org/viewvc?rev=883394&view=rev
>> Log:
>> Boolean.valueOf() is better than new Boolean()
>
> Is this available in 1.4? I thought I checked and saw no.
On 23/11/2009, Phil Steitz wrote:
> s...@apache.org wrote:
> > Author: sebb
> > Date: Mon Nov 23 16:18:50 2009
> > New Revision: 883394
> >
> > URL: http://svn.apache.org/viewvc?rev=883394&view=rev
> > Log:
> > Boolean.valueOf() is better than new Boolean()
>
> Is this available in 1.4? I
s...@apache.org wrote:
> Author: sebb
> Date: Mon Nov 23 16:18:50 2009
> New Revision: 883394
>
> URL: http://svn.apache.org/viewvc?rev=883394&view=rev
> Log:
> Boolean.valueOf() is better than new Boolean()
Is this available in 1.4? I thought I checked and saw no. Could be
this one is and othe
Mark Thomas wrote:
> sebb wrote:
>> Findbugs has lots of complaints that the DelegatingDatabaseMetaData
>> class methods may return null for methods which should be @NonNull.
>>
>> These are all of the form:
>>
>> public String getSchemaTerm() throws SQLException {
>> { try { return _me
sebb wrote:
> Findbugs has lots of complaints that the DelegatingDatabaseMetaData
> class methods may return null for methods which should be @NonNull.
>
> These are all of the form:
>
> public String getSchemaTerm() throws SQLException {
> { try { return _meta.getSchemaTerm(); }
>
Findbugs has lots of complaints that the DelegatingDatabaseMetaData
class methods may return null for methods which should be @NonNull.
These are all of the form:
public String getSchemaTerm() throws SQLException {
{ try { return _meta.getSchemaTerm(); }
catch (SQLException e)
Doug Bateman wrote:
> Howdy all,
>
> Tonight while browsing through the latest commons projects, it
> occurred to me the once modest commons project has grown substantially
> over time and has a lot of great stuff. There are now lots of sub
> projects. Actually, it's 37 active subprojects to be
Niall Pemberton wrote:
>
> [X] +1 Yes lets sponsor it
> [ ] -1 No because...
>
...
>
> [X] +1 Use the Commons mailing lists
> [ ] -1 Bad idea because...
>
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
sebb wrote:
> On 23/11/2009, Phil Steitz wrote:
>> sebb wrote:
>> > On 22/11/2009, Phil Steitz wrote:
>> >> sebb wrote:
>> >> > On 22/11/2009, Phil Steitz wrote:
>> >> >> I am running into some problems preparing for dbcp-1.3. I would
>> >> >> appreciate comments / patches on any of th
sebb wrote:
> On 23/11/2009, Henri Yandell wrote:
>> Given that the Sun JDK's SSL implementation has the same problem as
>> other SSL implementations, and given that Sun don't support the free
>> 1.4 and 1.5 versions (so no security fixes coming), I think we do a
>> disservice in even encouragi
On 23/11/2009, Phil Steitz wrote:
> sebb wrote:
> > On 22/11/2009, Phil Steitz wrote:
> >> sebb wrote:
> >> > On 22/11/2009, Phil Steitz wrote:
> >> >> I am running into some problems preparing for dbcp-1.3. I would
> >> >> appreciate comments / patches on any of the issues below.
> >
> We use some commons projects in one of our commercial products that
> uses in-browser applets. Size is very important for some of our
> customers who have clients connecting in from geographically remote
> outstations over links with about as much bandwidth as a piece of wet
> string.
>
> We ship
On 23/11/2009, Henri Yandell wrote:
> Given that the Sun JDK's SSL implementation has the same problem as
> other SSL implementations, and given that Sun don't support the free
> 1.4 and 1.5 versions (so no security fixes coming), I think we do a
> disservice in even encouraging people to stay
Hi folks,
really looking forward to that ...
[X] +1 Yes lets sponsor it
[ ] -1 No because...
[X] +1 Use the Commons mailing lists
[ ] -1 Bad idea because...
Cheers,
Siegfried Goeschl
Niall Pemberton wrote:
> Donald Woods and I have put together a proposal for the incubator to
> bring agima
2009/11/22 Doug Bateman :
>> It means much bigger jars. 3M jars when people complain about the
>> size of the 500k Collections jar. I think a lot of that is not the
>> size of the jar, but the ability to grok the fullness of the API -
>> anyone who actually cares about jar size should be using tool
2009/11/22 Doug Bateman :
>> It means much bigger jars. 3M jars when people complain about the
>> size of the 500k Collections jar. I think a lot of that is not the
>> size of the jar, but the ability to grok the fullness of the API -
>> anyone who actually cares about jar size should be using tool
> -Original Message-
> From: Henri Yandell [mailto:flame...@gmail.com]
> Sent: Sunday, November 22, 2009 21:17
> To: Commons Developers List
> Subject: Re: [dbcp] 1.3 release problems
>
> Given that the Sun JDK's SSL implementation has the same problem as
> other SSL implementations, and g
31 matches
Mail list logo