Vinod (hope it's first name),
1) As an end-user of SSH library i would prefer to have classes like
"SSHConnectionFactory" and "SSHConnection". Factory will be used to setup
different connection parameters, including (but not limited to) key exchange
rate, connection timeout, authentication scheme
On Apr 10, 2009, at 12:18 PM, Matt Benson wrote:
Is there any point in turning [logging] into me-too-slf4j? If we
can agree that slf4j's API is preferable to that of [logging] in its
current form, why don't we EOL [logging] and bless the compatibly-
licensed slf4j for future development?
Hi,
I don't think that TarArchiveInputStream should have that method:
copyEntryContents(OutputStream out) throws IOException
I copies the current read entry directly to an output stream which
mixes up reading and writing.
The method is never called in the workspace and I will remove it now.
If y
--- On Fri, 4/10/09, Oliver Heger wrote:
> From: Oliver Heger
> Subject: Re: [Configuration] experimental branch uses java.util.logging?
> To: "Commons Developers List"
> Date: Friday, April 10, 2009, 2:03 PM
> Ralph Goers schrieb:
> >
> > On Apr 10, 2009, at 11:40 AM, Oliver Heger wrote:
> >
Ralph Goers schrieb:
On Apr 10, 2009, at 11:40 AM, Oliver Heger wrote:
Ralph Goers schrieb:
I just noticed that this was changed from commons.logging. I'm very
strongly opposed to using j.u.l. I much prefer a logging abstraction.
While I'm not in love with commons-logging and would prefer S
On Apr 10, 2009, at 11:40 AM, Oliver Heger wrote:
Ralph Goers schrieb:
I just noticed that this was changed from commons.logging. I'm
very strongly opposed to using j.u.l. I much prefer a logging
abstraction. While I'm not in love with commons-logging and would
prefer SLF4J, using common
Ralph Goers schrieb:
I just noticed that this was changed from commons.logging. I'm very
strongly opposed to using j.u.l. I much prefer a logging abstraction.
While I'm not in love with commons-logging and would prefer SLF4J, using
commons-logging is better than using j.u.l directly. As I said
I just noticed that this was changed from commons.logging. I'm very
strongly opposed to using j.u.l. I much prefer a logging abstraction.
While I'm not in love with commons-logging and would prefer SLF4J,
using commons-logging is better than using j.u.l directly. As I said,
if there is som
:s/Unchecked/checked/
i suck.
On Fri, Apr 10, 2009 at 11:00 AM, Liam Coughlin wrote:
> The real problem is that Unchecked exceptions still exist, and are way over
> used.
>
> -shrug-
>
>
>
> On Fri, Apr 10, 2009 at 8:28 AM, Andre Dantas Rocha <
> andre.dantas.ro...@uol.com.br> wrote:
>
>> I tota
The real problem is that Unchecked exceptions still exist, and are way over
used.
-shrug-
On Fri, Apr 10, 2009 at 8:28 AM, Andre Dantas Rocha <
andre.dantas.ro...@uol.com.br> wrote:
> I totally agree with you about HandleUtil.handle(); this is a point that I
> want to avoid either. However, the
I totally agree with you about HandleUtil.handle(); this is a point that I
want to avoid either. However, the current weaving implementation isn't so
flexible and today this is the only way it works.
As I wrote in my last emails, it is still necessary to work on Mojo/weaving
to solve this kind of
Hi Matt,
In my opinion, there are basically three ways of doing this:
1) Specify supported exceptions in annotation:
@ExceptionHandler(validExceptions={RuntimeException.class,RemoteException.cl
ass}
2) Specify supported exception in Handler interface:
public interface Handler {
...
Class
Apologies for the late reply.
> But... and if does the user specify an handler that are not supposed to
> handle that code? Isn't better to throw an exception instead of returning
> the original one?
Hmm, when I think about it, I think it is better to throw the exception
than return it, returning
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-configuration-test has an issue affecting its community
integrati
14 matches
Mail list logo
