Hi Huxing,
since the PrintStream/PrintWriter are built around an existing (open)
OutputStream/Writer: the parameter passed to the method,
it is the responsibility of the caller to close the OutputStream/Writer.
Thus, there is no need to close the PrintStream/PrintWriter (they
would close the unde
The Commons Daemon team is pleased to announce the
commons-daemon-1.0.4 release!
Version 1.0.4 is primarily a bug fix release with
some new features added.
Source and binary distributions are available for download
from the Apache Commons download site:
http://commons.apache.org/daemon/download_
On Mon, Oct 25, 2010 at 7:44 PM, Ralph Goers wrote:
>
> This code has been sitting here for a year. Commons Configuration would like
> to do a release but cannot until VFS is released. I'd like to work on the VFS
> release during the hackathon next week. If you believe you can change how VFS
>
On Oct 25, 2010, at 9:01 AM, James Carman wrote:
> On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
> wrote:
>> I'm not in favor of changing much at this point. I'd really like to get a
>> release done without too many more changes.
>>
>
> There's a problem with that, Ralph. If we publish a 2.0
Hi!
Am 25.10.2010 um 21:13 schrieb "James Carman" :
> On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
> wrote:
>>
>> So for VFS, you would prefer that all error handling be done with unchecked
>>
>
> In a nutshell, yes. So, it's a pretty easy change. You'd just change
> the superclass of Fil
> -Original Message-
> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
> Behalf Of James Carman
> Sent: Monday, October 25, 2010 10:33
> To: Commons Developers List
> Subject: Re: [VFS] Softening the exceptions...
>
> On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortn
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
wrote:
>
> So for VFS, you would prefer that all error handling be done with unchecked
> exceptions?
>
This is probably a question better asked on the user list so we can
get a feel for how people feel about it. I just wanted to start the
discussion
On Mon, Oct 25, 2010 at 3:06 PM, Gary Gregory
wrote:
>
> So for VFS, you would prefer that all error handling be done with unchecked
> exceptions?
>
In a nutshell, yes. So, it's a pretty easy change. You'd just change
the superclass of FileSystemException.
> -Original Message-
> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
> Behalf Of James Carman
> Sent: Monday, October 25, 2010 08:10
> To: Commons Developers List
> Subject: Re: [VFS] Softening the exceptions...
>
> On Mon, Oct 25, 2010 at 11:05 AM, Gary Grego
> -Original Message-
> From: Phil Steitz [mailto:phil.ste...@gmail.com]
> Sent: Monday, October 25, 2010 08:50
> To: Commons Developers List
> Subject: Re: [pool] Reusing Config part 2
>
> On 10/25/10 11:26 AM, Gary Gregory wrote:
> > Thank you for working through this Simone.
> >
> > I wo
> -Original Message-
> From: Steven Siebert [mailto:smsi...@gmail.com]
> Sent: Monday, October 25, 2010 08:43
> To: Commons Developers List
> Subject: Re: [pool] Reusing Config part 2
>
> Gary,
>
> I tossed this around as well, and noted these fields as a "possible promote"
> to the Abst
Le 25/10/2010 11:42, er...@apache.org a écrit :
> Author: erans
> Date: Mon Oct 25 09:42:33 2010
> New Revision: 1027007
>
> URL: http://svn.apache.org/viewvc?rev=1027007&view=rev
> Log:
> MATH-428
> Refactoring of "DirectSearchOptimizer" to separate the optimization and
> simplex management aspec
On Mon, Oct 25, 2010 at 2:00 PM, Filip Defoort
wrote:
> Well, it's my job to write proper code. Other people can do all they
> want, but with just a runtime exception I wouldn't be able to do what
> I'd need to do.
>
Again, I think you're misunderstanding my suggestion. I'm suggesting
to do this
On Mon, Oct 25, 2010 at 10:56 AM, James Carman
wrote:
> On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort
> wrote:
>>
>> In my view, it is the developer's job to provide an solid experience
>> to the user. That includes properly dealing with underlying system
>> errors in the least cryptic possible
On Mon, Oct 25, 2010 at 1:55 PM, Filip Defoort
wrote:
>
> No, you can't. Yes you can catch them, but you really want to start
> parsing the text of the exception just to know what situation you're
> in ? I already have to do that with some of the exceptions in the
> mysql driver and it's a royal P
On Mon, Oct 25, 2010 at 1:53 PM, Filip Defoort
wrote:
>
> In my view, it is the developer's job to provide an solid experience
> to the user. That includes properly dealing with underlying system
> errors in the least cryptic possible way and recovering where
> possible. And those errors aren't al
On Mon, Oct 25, 2010 at 10:52 AM, James Carman
wrote:
> On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort
> wrote:
>>
>> Depends. I do have a bunch of wrappers for common types of retries,
>> but often the remedy really is different depending on the operation
>> (I'm dealing a lot with search indexe
On Mon, Oct 25, 2010 at 10:51 AM, Paul Benedict wrote:
> Checked exceptions throw a burden onto the developer. He is forced to
> do something. Why force this burden? It assumes something SHOULD be
> done for these particular errors. I don't think that's realistic
> (they're OS errors -- not busine
On Mon, Oct 25, 2010 at 1:48 PM, Filip Defoort
wrote:
>
> Depends. I do have a bunch of wrappers for common types of retries,
> but often the remedy really is different depending on the operation
> (I'm dealing a lot with search indexes, updating them and transaction
> locking).
>
Again, you can
Checked exceptions throw a burden onto the developer. He is forced to
do something. Why force this burden? It assumes something SHOULD be
done for these particular errors. I don't think that's realistic
(they're OS errors -- not business errors), which is why checked
exceptions have fallen well out
On Mon, Oct 25, 2010 at 10:45 AM, James Carman
wrote:
> On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
> wrote:
>>
>> Yes! Very much so. It's quite useful when dealing with stale nfs,
>> locked files,...
>>
>
> Do you implement the retry logic in every place where you need it or
> do you have a h
On Mon, Oct 25, 2010 at 1:17 PM, Steven Siebert wrote:
> I agree with Mark's point about unfamiliar developers benefiting from
> checked exceptions. Unlike James, I like checked exceptions =), and I have
> established "elegant" recoveries from various resource exceptions (IO, for
> example) under
On Mon, Oct 25, 2010 at 1:41 PM, Filip Defoort
wrote:
>
> Yes! Very much so. It's quite useful when dealing with stale nfs,
> locked files,...
>
Do you implement the retry logic in every place where you need it or
do you have a helper method that takes some sort of functor and it
wraps it in the
Very much -1 on unchecked exceptions.
On Mon, Oct 25, 2010 at 10:33 AM, James Carman
wrote:
>
> What do people typically do with those exceptions? Seriously, do you
> retry stuff on a regular basis in your catch blocks?
Yes! Very much so. It's quite useful when dealing with stale nfs,
locked fi
On Mon, Oct 25, 2010 at 12:49 PM, Mark Fortner wrote:
> -1
>
> At the risk of playing Devils Advocate here, what's the downside to checked
> exceptions? A few extra lines of code? I can foresee a problem with
> unchecked exceptions though. Imagine that you're using the API to build a
> desktop a
I agree with Mark's point about unfamiliar developers benefiting from
checked exceptions. Unlike James, I like checked exceptions =), and I have
established "elegant" recoveries from various resource exceptions (IO, for
example) under many use cases (at least in the enterprise arena).
What's ever
-1
At the risk of playing Devils Advocate here, what's the downside to checked
exceptions? A few extra lines of code? I can foresee a problem with
unchecked exceptions though. Imagine that you're using the API to build a
desktop application. You want to display a dialog box to the user
indicati
On 10/25/10 12:36 PM, James Carman wrote:
On Mon, Oct 25, 2010 at 12:25 PM, Phil Steitz wrote:
I notice now what I missed on initial review of Simo's patch - the pool
accessors now manage the config properties via persisted Config members. I
am OK with this, but it now means that the Config c
On Mon, Oct 25, 2010 at 12:25 PM, Phil Steitz wrote:
>
> I notice now what I missed on initial review of Simo's patch - the pool
> accessors now manage the config properties via persisted Config members. I
> am OK with this, but it now means that the Config classes have to be
> mutable. What nee
On 10/25/10 11:34 AM, Phil Steitz wrote:
On 10/25/10 11:22 AM, Steven Siebert wrote:
Phil,
I don't think we have removed the ability to access the config
options
programmatically from the config instance. You can either get a
reference
to it post-construct/build or from the getConfig() method o
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers
wrote:
> I'm not in favor of changing much at this point. I'd really like to get a
> release done without too many more changes.
>
There's a problem with that, Ralph. If we publish a 2.0, we can't
"break" the API later. So, we'd have to go to 3.0 i
+1 for softening all exceptions. The fact is, what reasonable recourse
is there to the user if a file operation fails? That's what checked
exceptions were supposed to be for -- mandate handling code. It's
tough to say we need to mandate handling these errors.
Paul
On Mon, Oct 25, 2010 at 10:49 AM
true =) BTW, I'll be at ApacheCon, if the VFS crew would like another warm
body to assist in getting the release out. Just let me know when/where to
be
On Mon, Oct 25, 2010 at 11:49 AM, Ralph Goers wrote:
>
> On Oct 25, 2010, at 8:10 AM, James Carman wrote:
>
> > On Mon, Oct 25, 2010 at 11:05 A
On 10/25/10 11:26 AM, Gary Gregory wrote:
Thank you for working through this Simone.
I would like to discuss something I took for granted in my experimental patch
for [POOL-173]. I can see that you took and a more conservative (and safer ;)
approach in your version. I am glad to see this becau
On Oct 25, 2010, at 8:10 AM, James Carman wrote:
> On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
> wrote:
>> Do we want the APIs to be quieter than using java.io.File for example? Or,
>> should exceptions be thrown from similar places?
>>
>
> Definitely quieter than java.io.File! I *hate* t
Gary,
I tossed this around as well, and noted these fields as a "possible promote"
to the Abstract configuration, because I agree that there probably isn't a
"good" reason why one pool has those features and the other doesn't. (if
this is indeed the case, these would probably best be tracked in
On 10/25/10 11:22 AM, Steven Siebert wrote:
Phil,
I don't think we have removed the ability to access the config options
programmatically from the config instance. You can either get a reference
to it post-construct/build or from the getConfig() method on the pool.
Non-config properties remai
Thank you for working through this Simone.
I would like to discuss something I took for granted in my experimental patch
for [POOL-173]. I can see that you took and a more conservative (and safer ;)
approach in your version. I am glad to see this because we can now more easily
discuss it becau
Phil,
I don't think we have removed the ability to access the config options
programmatically from the config instance. You can either get a reference
to it post-construct/build or from the getConfig() method on the pool.
Non-config properties remain the same, accessible through the pool API.
T
On 10/25/10 9:06 AM, Steven Siebert wrote:
Hi Simone,
You have two +1's waiting for you in the JIRA comments =)
My comments from tracker:
"I took a look at this last night but didn't get a chance to comment =)
I like the patch, I believe this does indeed satisfy the issue.
One question I hav
On Mon, Oct 25, 2010 at 11:05 AM, Gary Gregory
wrote:
> Do we want the APIs to be quieter than using java.io.File for example? Or,
> should exceptions be thrown from similar places?
>
Definitely quieter than java.io.File! I *hate* that API for its
checked exceptions.
> I am worried that we wou
Do we want the APIs to be quieter than using java.io.File for example? Or,
should exceptions be thrown from similar places?
I am worried that we would make all APIs "quiet" (unchecked exceptions) as a
opposed to really thinking where exceptions should be checked or return an
Boolean error code
I've even gone as far as writing a VfsUtils class that does all the
wrapping of these exceptions into RuntimeExceptions so that the API is
less of a burden.
On Mon, Oct 25, 2010 at 10:53 AM, Steven Siebert wrote:
> +1 on this issue.
>
> I use VFS on a couple projects and this is always a bit burd
On 10/25/10 10:51 AM, Steven Siebert wrote:
Simo,
You make a good point, especially with the groupId/package change.
POOL-169 did implement some deprecations for changes from 1.5 to 2.0, so
this isn't without precedent and consistency (even for the sake of
consistency in commons-* subprojects,
+1 on this issue.
I use VFS on a couple projects and this is always a bit burdensome, and on
several occasions have indeed caught and rethrew RuntimeExceptions. Even if
we can't/shouldn't soften them, what about typing them to be more specific?
Having every method throwing a FileSystemException
Simo,
You make a good point, especially with the groupId/package change.
POOL-169 did implement some deprecations for changes from 1.5 to 2.0, so
this isn't without precedent and consistency (even for the sake of
consistency in commons-* subprojects, IMO) is important. Honestly, I could
go eithe
What do you folks think about making the exceptions extend
RuntimeException in 2.0? I really find it tedious to do try/catch
everywhere I want to ask a FileObject something (like if it exists or
not).
-
To unsubscribe, e-mail: de
Hi Steven :)
thanks for the explanation, as far as I understand there are a lot of
things I can learn from you about JMX so I started feeling impatient
to see your commits :P
I don't think we should mark with @Deprecate removed ctors, classes
are now living in a fresh new package so, as user, I wo
Simone,
I'm sorry I'm confusing, so many thoughts going though my mind =)
yes, I think the best approach is to provide a separate class for the
JMX...but I'm thinking that doing a private inner class (non-static) in each
pool would be the cleanest way to do so. This way, the MBean (instance)
wou
Hi Steven,
very sorry to have missed the Jira notifications, just checked now
after read your email. Sorry! :(
I thought the idea was adding JMX support directly on factory/pool and
not on Configuration, btw not being JMX expert this will be a good
chance to learn... I'll fill a new Jira issue for
Dear Apache Commons IO developers,
I found there might be a close method missing in the source code of test cases,
which may be an issue.
No patch seems to be applied till revision 1026932.
How do you guys think?
The original code here is:
In io/trunk/src/test/java/org/apache/commons/io/testtools
Hi Simone,
You have two +1's waiting for you in the JIRA comments =)
My comments from tracker:
"I took a look at this last night but didn't get a chance to comment =)
I like the patch, I believe this does indeed satisfy the issue.
One question I have, since we're eliminating the primitive conf
On 10/25/2010 02:42 PM, Jörg Schaible wrote:
Mladen Turk wrote:
With my vote we have 5 binding votes.
(Sebastian, Niall, Phil, Bill and I)
You had 6:
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/116173/focus=116189
Sorry I was automatically rule out non @apache.org address
well
Mladen Turk wrote:
> With my vote we have 5 binding votes.
> (Sebastian, Niall, Phil, Bill and I)
You had 6:
http://thread.gmane.org/gmane.comp.jakarta.commons.devel/116173/focus=116189
- Jörg
-
To unsubscribe, e-mail: dev-un
Hi all mates,
I updated the jira issue uploading my patch; it contains the
configuration extraction and some code modification.
IMHO we shouldn't replicate the same data in both configuration AND
factory/pool, when creating the factory/pool it is enough storing the
configuration reference, just use
With my vote we have 5 binding votes.
(Sebastian, Niall, Phil, Bill and I)
I'll proceed with uploading the artifacts to dist
and create an Announcement once when mirrors pick that up.
On 10/21/2010 09:57 AM, Mladen Turk wrote:
Hi,
Commons Daemon 1.0.4 RC1 release is available for testing at:
On 10/21/10 3:57 AM, Mladen Turk wrote:
Hi,
Commons Daemon 1.0.4 RC1 release is available for testing at:
http://people.apache.org/~mturk/daemon/
The SVN tag is:
https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_4_RC1
(If voted will be renamed to COMMONS_DAEMON_1_0_
57 matches
Mail list logo
