Re: [dbcp] Jumping in...

I just use the hugely long: http://issues.apache.org/bugzilla/report.cgi?x_axis_field=bug_status&y_axis_field=component&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=Commons&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_f

RE: [lang] this.foo() vs. foo()

> Back to the original post, my preference is against "this.foo()" > because I'd bet the compiler generates more bytecode for the "this." Sorry, you are betting on the wrong horse. The Java Virtual Machine Specification [1] defines the invokevirtual instruction to push on the stack the receiver of

DO NOT REPLY [Bug 36998] - [cli] Parsing error?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36892] - [sandbox] Create a "secure" package

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36998] - [cli] Parsing error?

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38873] - [email] setCharset() in Email does not set the charset for the message content

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38609] - [cli][PATCH] HelpWriter.printWrapped() should have public access

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r384140 - in /jakarta/commons/proper/cli/trunk/src: java/org/apache/commons/cli2/util/HelpFormatter.java test/org/apache/commons/cli2/util/HelpFormatterTest.java

Author: bayard Date: Tue Mar 7 23:17:00 2006 New Revision: 384140 URL: http://svn.apache.org/viewcvs?rev=384140&view=rev Log: Applying patch #17677. Remove the Writer API in favour of the PrintWriter API it is using elsewhere anyway - with the advantage that the IOException throws go away Modi

DO NOT REPLY [Bug 38611] - [cli][PATCH] HelpFormatter shouldn't throw IOException

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38845] - [cli] DateValidatorTest & FileValidatorTest problems

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r384139 - /jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/validation/DateValidatorTest.java

Author: bayard Date: Tue Mar 7 23:13:07 2006 New Revision: 384139 URL: http://svn.apache.org/viewcvs?rev=384139&view=rev Log: As #38845 states, three tests in this class fail. This is because they make assumptions about the default datetime formatting instances. I've made them non-default, whic

[dbcp] Connection.close() implementation issues [was: Jumping in...]

Sorry, ment to send this to commons-dev, not commons-user. /me needs sleep asap. -- Forwarded message -- From: Sandy McArthur <[EMAIL PROTECTED]> Date: Mar 8, 2006 2:00 AM Subject: [dbcp] Connection.close() implementation issues [was: Jumping in...] To: Jakarta Commons Users List

DO NOT REPLY [Bug 36295] - [cli] options group cannot have long options

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 36185] - [cli] supporting options without a short option

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 34831] - [cli] Parameter value "-something" misinterpreted as a parameter

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r384132 - /jakarta/commons/proper/cli/trunk/src/java/org/apache/commons/cli/Option.java

Author: bayard Date: Tue Mar 7 22:42:27 2006 New Revision: 384132 URL: http://svn.apache.org/viewcvs?rev=384132&view=rev Log: Removed clone() method - it was incorrectly implemented, but more importantly there is no obvious reason for Option to be cloneable. This resolves #28482 and #29908 Mod

DO NOT REPLY [Bug 29908] - [cli] clone method in Option should use super.clone()

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28482] - [cli] clone() method doesn't fully clone contents

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 29908] - [cli] clone method in Option should use super.clone()

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 28482] - [cli] clone() method doesn't fully clone contents

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33591] - [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38843] - [cli] testNewMessage1Param fails

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38842] - [cli] Dependecy on commons-lang-2.0 but commons-lang-1.0 is obtained

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33591] - [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r384129 - in /jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2: DocumentationTest.java PrecedenceTest.java WriteableCommandLineTestCase.java jdepend/JDependTest.java

Author: bayard Date: Tue Mar 7 22:11:58 2006 New Revision: 384129 URL: http://svn.apache.org/viewcvs?rev=384129&view=rev Log: Removed Eclipse auto generated crap Modified: jakarta/commons/proper/cli/trunk/src/test/org/apache/commons/cli2/DocumentationTest.java jakarta/commons/proper/cl

svn commit: r384127 - in /jakarta/commons/proper/cli/trunk: maven.xml project.properties

Author: bayard Date: Tue Mar 7 22:05:02 2006 New Revision: 384127 URL: http://svn.apache.org/viewcvs?rev=384127&view=rev Log: Removed the pdf and svg bits - not sure why [cli] would have these, yell at me if there's a reason Modified: jakarta/commons/proper/cli/trunk/maven.xml jakarta/c

Re: [dbcp] Jumping in...

Thanks! I added the new commons std issue tracking page here: http://jakarta.apache.org/commons/dbcp/issue-tracking.html One of the links on that page will generate an open bug list. There are also instructions for entering new ones (though we are certainly not lacking in open tickets ;-) Anyon

DO NOT REPLY [Bug 23217] - [messenger] Messenger.dtd's JNDI attributes rules mistakenly require className

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 27997] - [messenger] Patch - Messenger instance continues to work after JMS server crash

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r384125 - /jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml

Author: psteitz Date: Tue Mar 7 21:50:46 2006 New Revision: 384125 URL: http://svn.apache.org/viewcvs?rev=384125&view=rev Log: Added new standard issue tracking page. Added: jakarta/commons/proper/dbcp/trunk/xdocs/issue-tracking.xml (with props) Added: jakarta/commons/proper/dbcp/trunk/xd

DO NOT REPLY [Bug 30483] - [codec] Base64 decoder throws exception if byte sent in < 0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33591] - [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [dbcp] Jumping in...

On 3/7/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 3/7/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > > > > There is a growing backlog of bugs open against [dbcp]. Unless other > > committers object, I am going to jump in and start committing patches > > and develop a maintenance release pl

Re: [io] LineIterator suggestions [was: LineIterator finalize]

Stephen Colebourne wrote: > > I also put closeQuietly back into the tests. Without the try-finally and > closeQuietly, a test failure was hidden by other errors. This emphasises > the value of the usage pattern to me. (non-binding) +1 to retaining closeQuietly. michael

Re: [lang] this.foo() vs. foo()

On 3/7/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 3/7/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > > On 3/7/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > > On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: > > > > In our product code bases, we use the "this.foo()" convention. The > > > >

Re: [dbcp] Jumping in...

On 3/7/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > > There is a growing backlog of bugs open against [dbcp]. Unless other > committers object, I am going to jump in and start committing patches > and develop a maintenance release plan. +1 (and thanks) for Phil stepping up to the plate! Craig

Re: [dbcp] Jumping in...

I'm not familar with the dbcp codebase yet but near the release of Pool 2.0 it is my intention to get familar with it and make sure it works well with the semantic changes. Maybe also switch dbcp to the composite pool impl if that is acceptable to everyone. In the mean go for it. On 3/7/06, Phil

Re: [dbcp] Jumping in...

Hi Phil, On Wednesday 08 March 2006 14:07, Phil Steitz wrote: > Thanks in advance for your help. On 33591 specifically, any comments > that you have on which of the solutions in the ticket is cleanest / > safest would be appreciated. I am testing your patch now, but am also > evaluating Dirk's.

Re: [dbcp] Jumping in...

On 3/7/06, James Ring <[EMAIL PROTECTED]> wrote: > Hi Phil, > > On Wednesday 08 March 2006 13:32, Phil Steitz wrote: > > There is a growing backlog of bugs open against [dbcp]. Unless other > > committers object, I am going to jump in and start committing patches > > and develop a maintenance rele

Re: [dbcp] Jumping in...

Hi Phil, On Wednesday 08 March 2006 13:32, Phil Steitz wrote: > There is a growing backlog of bugs open against [dbcp]. Unless other > committers object, I am going to jump in and start committing patches > and develop a maintenance release plan. I plan to start with > > http://issues.apache.org

[dbcp] Jumping in...

There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. I plan to start with http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 http://issues.apache.org/bugzilla/show_b

svn commit: r384095 - /jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/CharEncodingTest.java

Author: ggregory Date: Tue Mar 7 18:25:50 2006 New Revision: 384095 URL: http://svn.apache.org/viewcvs?rev=384095&view=rev Log: Cobertura unit test coverage is now 100%. Modified: jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/CharEncodingTest.java Modified: jakarta/co

Re: [lang] this.foo() vs. foo()

On 3/7/06, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 3/7/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: > > > In our product code bases, we use the "this.foo()" convention. The > > > argument being, that in object oriented programming, a messa

Re: [logging] Re: svn commit: r383771 - /jakarta/commons/proper/logging/contrib/simon/jcl2/build.xml

On Tue, 2006-03-07 at 20:15 +, robert burrell donkin wrote: > On Tue, 2006-03-07 at 17:01 +, Stephen Colebourne wrote: > > Er, I think I would have to -1 a release without an ant build, so I'm > > hoping this is temporary :-) > > AIUI simon's working in contrib on some ideas for JCL2. the

RE: [lang] this.foo() vs. foo()

> How does the list feel about cleaning up foo()'s to this.foo()'s? IMO, a waste of time. Java isn't Smalltalk, and this isn't self. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:

[Jakarta-commons Wiki] Update of "Logging/StaticLog" by SimonKitching

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-commons Wiki" for change notification. The following page has been changed by SimonKitching: http://wiki.apache.org/jakarta-commons/Logging/StaticLog The comment on the change is: Add sections on java.util.logging a

Re: [lang] this.foo() vs. foo()

On 08.03.2006, at 11:17, Henri Yandell wrote: On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: Hello: This could be a religious issue... look out! In our product code bases, we use the "this.foo()" convention. The argument being, that in object oriented programming, a message is sent to

Re: [lang] this.foo() vs. foo()

On 08.03.2006, at 11:05, Gary Gregory wrote: hate it :) Joke and emotion aside, I am interested in what makes programmers take an opinion on topics like this. Could you describe what you like about the one syntax? As long as we don't make long winded discussion out of it - sure :) Well, I

Re: [lang] this.foo() vs. foo()

On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: > Hello: > > This could be a religious issue... look out! > > In our product code bases, we use the "this.foo()" convention. The > argument being, that in object oriented programming, a message is sent > to an object, always. > > How does the list

Re: [io] LineIterator suggestions [was: LineIterator finalize]

On 3/7/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Let me know if you still have issues, as I'd like to release. No issues. I still have my opinions but until I've conqured the world don't let that hold anything up. :-) -- Sandy McArthur "He who dares not offend cannot be honest." - Thom

RE: [lang] this.foo() vs. foo()

> My position is that as you're working on a chunk of code, clean it up > to whatever you like but DO NOT go changing code just for cosmetic > sake. Fair enough. Personally, I like the idea that a release has a uniform look and feel, it give me the feeling that I am dealing with a /coherent whol

Re: [lang] this.foo() vs. foo()

On 3/7/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: > > In our product code bases, we use the "this.foo()" convention. The > > argument being, that in object oriented programming, a message is sent > > to an object, always. > > > > How does the

Re: [lang] this.foo() vs. foo()

On 3/7/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > > On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: > > In our product code bases, we use the "this.foo()" convention. The > > argument being, that in object oriented programming, a message is sent > > to an object, always. > > > > How does th

RE: [lang] this.foo() vs. foo()

> hate it :) Joke and emotion aside, I am interested in what makes programmers take an opinion on topics like this. Could you describe what you like about the one syntax? Could you categorize your POV, perhaps one of: - I do like change - I like foo() because: - I like this.foo() because: -

Re: [lang] this.foo() vs. foo()

On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: > In our product code bases, we use the "this.foo()" convention. The > argument being, that in object oriented programming, a message is sent > to an object, always. > > How does the list feel about cleaning up foo()'s to this.foo()'s? > > I am wil

Re: [lang] this.foo() vs. foo()

This could be a religious issue... look out! yepp In our product code bases, we use the "this.foo()" convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? hate it :) che

RE: [lang] this.foo() vs. foo()

> Will this.foo() and foo() always result in the same behaviour, > particularly > when you're dealing with overridden methods? I ask because I am unsure! Yes. I consider the missing receiver a syntactic shortcut which only creates an exception to the simple "object.message()" syntax. Gary >

Re: [lang] this.foo() vs. foo()

Hi Gary, On Wednesday 08 March 2006 10:35, Gary Gregory wrote: > Hello: > > This could be a religious issue... look out! > > In our product code bases, we use the "this.foo()" convention. The > argument being, that in object oriented programming, a message is sent > to an object, always. Will thi

[lang] this.foo() vs. foo()

Hello: This could be a religious issue... look out! In our product code bases, we use the "this.foo()" convention. The argument being, that in object oriented programming, a message is sent to an object, always. How does the list feel about cleaning up foo()'s to this.foo()'s? I am willing to d

RE: [lang] VariableFormatter and text package

Hello: Personally, I like the VariableFormatter class and plan on using it in production. For me, this class is what is motivating me to push for a 2.2 release (3.0 seems like release inflation ;) I agree that VariableFormatter appears complex, but that is OK to me given the flexibility it provid

RE: [lang] VariableFormatter and text package

As a reference, here is a thread about this class: http://marc.theaimsgroup.com/?t=11230087692&r=1&w=2 Gary > -Original Message- > From: Stephen Colebourne [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 07, 2006 3:04 PM > To: Jakarta Commons Developers List > Subject: [lang] Variab

[lang] VariableFormatter and text package

This class is my main hold-up for release 2.2. Somehow, I just don't like it. It seems way complex for what it appears to do. Thats a gut feel reaction however - I can't get my head around the code easily (another negative). More specifically, there is no way to substitute the variables in a

DO NOT REPLY [Bug 33591] - [dbcp][PATCH] Connection leak in PoolableConnection.close() (Oracle 10g driver)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33591] - [dbcp] Connection leak in PoolableConnection.close() (Oracle 10g driver)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 33591] - [dbcp] Connection leak in PoolableConnection.close() (Oracle 10g driver)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r384043 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java

Author: scolebourne Date: Tue Mar 7 14:43:39 2006 New Revision: 384043 URL: http://svn.apache.org/viewcvs?rev=384043&view=rev Log: Fix code style Modified: jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java Modified: jakarta/commons/proper/lang/trunk/src/j

Re: [all] Rest of commons

On 3/7/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Rahul Akolkar wrote: > > > > If this proposal means a departure from the "rest of Commons" of the > > part of the community that is interesting only in JLC, then this is a > > loss. While you (Stephen) may be inclined towards the shallow-b

Re: [io] LineIterator suggestions [was: LineIterator finalize]

I made some more adjustments to your checkin. In particular I put the example code back in. I am choosing not to mention garbage collection, as I don't trust our users not to complain. (If a particular user knows enough to leave it to gc then they don't need to docs anyway) I also put closeQui

svn commit: r384037 - in /jakarta/commons/proper/io/trunk/src: java/org/apache/commons/io/FileUtils.java java/org/apache/commons/io/IOUtils.java java/org/apache/commons/io/LineIterator.java test/org/a

Author: scolebourne Date: Tue Mar 7 14:26:37 2006 New Revision: 384037 URL: http://svn.apache.org/viewcvs?rev=384037&view=rev Log: Further adjustments to javadoc/implementation of LineIterator Modified: jakarta/commons/proper/io/trunk/src/java/org/apache/commons/io/FileUtils.java jakart

Re: svn commit: r384025 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

please take a look and check for typo's, bugs etc. i'm working on something for the troubleshooting documentation about this. - robert On Tue, 2006-03-07 at 21:54 +, [EMAIL PROTECTED] wrote: > Author: rdonkin > Date: Tue Mar 7 13:54:57 2006 > New Revision: 384025 > > URL: http://svn.apach

svn commit: r384025 - /jakarta/commons/proper/logging/trunk/src/java/org/apache/commons/logging/LogFactory.java

Author: rdonkin Date: Tue Mar 7 13:54:57 2006 New Revision: 384025 URL: http://svn.apache.org/viewcvs?rev=384025&view=rev Log: Improved diagnostics and added more information to the message thrown when a custom LogFactory cannot be loaded due to classloader incompatibilities. Modified: jak

Re: [all] Rest of commons

On 3/7/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > Rahul Akolkar wrote: > > To the effect of what Hen says later in this thread, its the > > narrow-deep bits that have been the "ugly ducklings", whereas it has > > been proven sufficient number of times that both "categories" are > > extreme

Re: [compress] Introducing the Compress-Interface

Henri Yandell wrote: > However, what do people think about: > > https://truezip.dev.java.net/ It doesn't yet have tar support (seems to have a different initial focus than what we are looking for), one developer, zero users (4 messages to the user list, all from the devleoper), and a rapid change

DO NOT REPLY [Bug 33591] - [dbcp] Connection leak in PoolableConnection.close() (Oracle 10g driver)

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r384022 - /jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt

Author: scolebourne Date: Tue Mar 7 13:34:17 2006 New Revision: 384022 URL: http://svn.apache.org/viewcvs?rev=384022&view=rev Log: Reword compatibility sectin title Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt Modified: jakarta/commons/proper/io/trunk/RELEASE-NOTES.txt URL:

[all] Rest of commons

Rahul Akolkar wrote: To the effect of what Hen says later in this thread, its the narrow-deep bits that have been the "ugly ducklings", whereas it has been proven sufficient number of times that both "categories" are extremely useful (for example, think of the number of ASF projects that use dige

DO NOT REPLY [Bug 38792] - [lang] Memory "leak" in StringUtils

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

svn commit: r384017 - /jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringUtils.java

Author: sandymac Date: Tue Mar 7 13:17:46 2006 New Revision: 384017 URL: http://svn.apache.org/viewcvs?rev=384017&view=rev Log: Removed PADDING cache which leaked memory. Issue #38792. Updated padding(int,char) JavaDoc about it's I18N incompatabilities. Modified: jakarta/commons/proper/lang

Re: [compress] Introducing the Compress-Interface

On 3/7/06, Sandy McArthur <[EMAIL PROTECTED]> wrote: > First, I don't think a compress project does much new. VFS already > seems to provide read-only access to common archive types. The JDK > comes with read-write support for Zip and Gzip files. And Ant has > read-write support for Zip, Tar, Gzip,

Re: [lang] lazy load of PADDING in StringUtils and Release

On 3/7/06, Stephen Colebourne <[EMAIL PROTECTED]> wrote: > If you commit > - remove the cache - its a bad idea by cache do you mean PADDING? yea, that is gone. > - use o.a.c.l.StrBuilder not StringBuffer its non-sync I actually just now decied it will be fastest to just create and fill a char[]

DO NOT REPLY [Bug 38792] - [lang] Memory "leak" in StringUtils

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: [lang] lazy load of PADDING in StringUtils and Release

Dunno yet, I'm just starting to go through the issues. Abougt 33% of them are new since the last release I think. Another question - 2.2 or 3.0? Hen On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: > Hello: > > Can we take care of this PADDING issue and think of a release? It's been > too long

RE: [lang] lazy load of PADDING in StringUtils and Release

Ah? It turns out that I want to use the formatter in the text package. The last time I looked at it and added more tests it seemed fine. Is there anything in particular that needs addressing? The unit test coverage from Corbertura is 98% which should be easy to get to 100% Gary > -Original Me

Re: [lang] lazy load of PADDING in StringUtils and Release

If you commit - remove the cache - its a bad idea - use o.a.c.l.StrBuilder not StringBuffer its non-sync Stephen Sandy McArthur wrote: Since no one seems to object I'll commit what I described here shortly: http://issues.apache.org/bugzilla/show_bug.cgi?id=38792#c3 On 3/7/06, Gary Gregory <[E

Re: [lang] lazy load of PADDING in StringUtils and Release

Since no one seems to object I'll commit what I described here shortly: http://issues.apache.org/bugzilla/show_bug.cgi?id=38792#c3 On 3/7/06, Gary Gregory <[EMAIL PROTECTED]> wrote: > Hello: > > Can we take care of this PADDING issue and think of a release? It's been > too long IMO. Are there any

Re: [lang] lazy load of PADDING in StringUtils and Release

I think there is still work in the text package, notably on the formatter. Stephen Gary Gregory wrote: Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary -Original Message- From: Henri Yandell [mailto:[EMAIL

Re: [logging] Re: svn commit: r383771 - /jakarta/commons/proper/logging/contrib/simon/jcl2/build.xml

On Tue, 2006-03-07 at 17:01 +, Stephen Colebourne wrote: > Er, I think I would have to -1 a release without an ant build, so I'm > hoping this is temporary :-) AIUI simon's working in contrib on some ideas for JCL2. the work on the (much delayed) JCL 1.1 release is happening on trunk. - robe

[lang] lazy load of PADDING in StringUtils and Release

Hello: Can we take care of this PADDING issue and think of a release? It's been too long IMO. Are there any roadblocks? Gary > -Original Message- > From: Henri Yandell [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 05, 2006 11:34 PM > To: Jakarta Commons Developers List > Subject: [lang

DO NOT REPLY [Bug 38887] - Warning in javascript with firefox 1.5

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38887] New: - Warning in javascript with firefox 1.5

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

RE: Commons Metadata?

Well, that's the thing. That's up to the "decorator" to decide how it gets the metadata information. Jakarta Commons Attributes does a pre-compilation step to set up the .class files so that their attributes can be read from them (from what I can glean from the docs). -Original Message-

Re: [compress] Introducing the Compress-Interface

First, I don't think a compress project does much new. VFS already seems to provide read-only access to common archive types. The JDK comes with read-write support for Zip and Gzip files. And Ant has read-write support for Zip, Tar, Gzip, Bzip2 and maybe others. If you're going to start a new proj

Re: Commons Metadata?

On 3/7/06, James Carman <[EMAIL PROTECTED]> wrote: > I believe I brought this up before, but I really think there's a need for > this. We need a metadata framework which abstracts away the details of > exactly how the metadata is found/provided. For example, some applications > use only JDK5 ann

Commons Metadata?

I believe I brought this up before, but I really think there's a need for this. We need a metadata framework which abstracts away the details of exactly how the metadata is found/provided. For example, some applications use only JDK5 annotations to add metadata to their classes. Others might use

DO NOT REPLY [Bug 38885] New: - [jc] Compiler interface changes

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[logging] Re: svn commit: r383771 - /jakarta/commons/proper/logging/contrib/simon/jcl2/build.xml

Er, I think I would have to -1 a release without an ant build, so I'm hoping this is temporary :-) Stephen [EMAIL PROTECTED] wrote: Author: skitching Date: Mon Mar 6 20:17:34 2006 New Revision: 383771 URL: http://svn.apache.org/viewcvs?rev=383771&view=rev Log: Ant buildfile now obsolete, rep

DO NOT REPLY [Bug 38881] - [fileupload] Item Iterator found empty in second pass for the same request

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 38881] - [fileupload] Item Iterator found empty in second pass for the same request

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[compress] Introducing the Compress-Interface

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, after thinking a lot about the difference of archivers and compressors, i am not sure how to proceed with it. At the moment [1], we have an Archiv Interface. This fits fine for Tar and Zip. If we imagine gunzip or bzip2 as an archive for an si

DO NOT REPLY [Bug 38881] New: - Item Iterator found empty in second pass for the same request

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

  1   2   >