[g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed
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 integration. This issue affects 1 projects, and has been outstanding for 6 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/configuration/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html Work Name: build_apache-commons_commons-configuration-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 32 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/configuration] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.7-SNAPSHOT.jar - testAddNodesCopy(org.apache.commons.configuration.TestXMLConfiguration) testInitCopy(org.apache.commons.configuration.TestXMLConfiguration) testSetRootAttribute(org.apache.commons.configuration.TestXMLConfiguration) testLoadAndSaveFromFile(org.apache.commons.configuration.TestXMLConfiguration) testSaveToURL(org.apache.commons.configuration.TestXMLConfiguration) testSaveToStream(org.apache.commons.configuration.TestXMLConfiguration) testAutoSave(org.apache.commons.configuration.TestXMLConfiguration) testSaveAttributes(org.apache.commons.configuration.TestXMLConfiguration) testCloneWithSave(org.apache.commons.configuration.TestXMLConfiguration) testEmptyElements(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithNullEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctype(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctypeIDs(org.apache.commons.configuration.TestXMLConfiguration) testSubsetWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationsAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testGetKeysWithReload(org.apache.commons.configuration.TestXMLConfiguration) testSetTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testClearTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabledAttrs(org.apache.commons.configuration.TestXMLConfiguration) testMultipleAttrValuesEscaped(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithReloadingStrategy(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveAddNodes(org.apache.commons.configuration.TestXMLConfiguration) testAddNodesAndSave(org.apache.commons.configuration.TestXMLConfiguration) testRegisterEntityId(org.apache.commons.configuration.TestXMLConfiguration) testSaveAfterCreateWithCopyConstructor(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootName(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootNameNoDocument(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidation(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidationFailure(org.apache.commons.configuration.TestXMLConfiguration) Tests run: 1413, Failures: 0, Errors: 51, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] ---
Re: RES: RES: RES: Possible incubation?
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 would again cause extra code in the caller.
I just want to touch up on a point you mentioned in your other mail about
HandlerUtil.handle(). I personally would love to avoid such a call at all.
I think the entire framework should be as transparent as possible to avoid
unnecessary code. The annotation already provides metadata for a developer
to refer too so there isn't a need for an explicit call.
Gaurav
> I agree with you in some points. Maybe it is better to return inside
> exceptions to the caller instead of catch them locally.
>
> The problem, for me, remains in this part: "see if we have a method to
> handle such an exception by checking if a method
> handleIllegalArgumentException exists"
>
> I believe that implement an handleIllegalArgumentException() method it's
> not
> the best solution for the problem. Maybe the best strategy is to overload
> handle() method for handling exceptions of handler's responsibility. For
> example, Instead of handleIllegalArgumentException(), codify a
> handle(IllegalArgumentException e):
>
> public class MyHandler implements handler {
>public Throwable handle(IllegalArgumentException e, ...) {
> // specific code
>}
>
>public Throwable handle(Throwable t, ...) {
> return t;
>}
> }
>
> 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?
>
> Andre
>
>
> -Mensagem original-
> De: Gaurav Arora [mailto:gauravar...@codercorp.com]
> Enviada em: quarta-feira, 8 de abril de 2009 12:37
> Para: Commons Developers List
> Assunto: Re: RES: RES: Possible incubation?
>
> I agree with you that there is no elegant way to say what can and cannot
> be handled by the handler so what I suggest is let the handler decide what
> it can and cannot handle. Looking at the handler should give one a clear
> picture of what its equipped to handle.
>
> Here's what I mean with an example:
>
> @ExceptionHandler(MyHandler.class)
> public void foo() {
> try {
> doSomething();
> } catch (Exception ex) {
> handler.handle(ex);
> }
> }
>
> Assume the above method throws an IllegalArgumentException.
>
> In our handler:
> public Throwable handle(Exception e) {
> // get the type of exception
> // see if we have a method to handle such an exception by checking if
> a method handleIllegalArgumentException exists
> // if we don't simply return the exception back
> }
>
> This way there is no need to explicitly define what exceptions can and
> cannot be handled. What is not handled is simply thrown back to the
> caller. But what it does is provides a very clean caller in the sense that
> it has no actual exception handling code, just a single catchAll.
>
> I am not sure on what exceptions should be handled by the handle method
> itself. Asking the handler to handle all it's own exceptions, in a way,
> again asks you to duplicate the code, which is what Jeha is trying to
> remove. Otherwise, you'll need to define exception handlers for the
> handlers themselves which in my view can get tricky real fast.
>
> I don't think that the option of rethrowing should rest with the caller.
> What the caller is saying is that the handler will handle all it's
> exceptions and it itself knows nothing about what is going on. Asking the
> caller to handle rethrows sort of splits the responsibility between the
> two which again, is something that can get tricky.
>
> Gaurav
>
>
>> Hi Gurav,
>>
>> The weaving could be accomplished statically using ASM, BCEL, Javassist
>> or
>> any similar tool. In my opinion, a bytecode library must be used only
>> during
>> compilation process; it's better (and cleaner) if the program does not
>> need
>> it to work.
>>
>> Personally, I think that attach handlers with specific exception types
>> could
>> be a problem when you have a method that throws exceptions of different
>> kinds. I don't think that it could be specified (in a elegant way) in
>> annotations. Maybe it preferable to let it more generic...
>>
>> I believe that the strategy of rethrowing an exception or not must be
>> accomplished by the caller method, and exceptions inside the handler
>> must
>> be
>> tackled there. Maybe a (new) parameter could specify what to do.
>>
>> What do you think?
>>
>> Andre
>>
>>
>>
>> -Mensagem original-
>> De: Gaurav Arora [mailto:gauravar...@codercorp.com]
>> Enviada em: quarta-feira, 8 de abril de 2009 10:37
>> Para: Commons Developers List
>> Assunto: Re: RES: Possible incubation?
>>
>> I just want to take the discussion towards converting compile time
>> weaving
>> to load time weaving for a second here. Pleas
RES: Possible incubation?
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[] validExceptions();
}
3) Overload methods in Handler implementation to tackle specific exceptions.
In some way they must work together.
Andre
-Mensagem original-
De: Matt Benson [mailto:gudnabr...@yahoo.com]
Enviada em: quarta-feira, 8 de abril de 2009 16:02
Para: Commons Developers List
Assunto: Re: RES: RES: RES: Possible incubation?
Perhaps the annotation could be extended in some way to permit mappings of
Throwable types to Handler types. This would (a) allow different handlers
to be used for the same method, and (b) allow the exception to be thrown as
normal when no matching handler was found.
Just thinking,
Matt
--- On Wed, 4/8/09, Andre Dantas Rocha
wrote:
> From: Andre Dantas Rocha
> Subject: RES: RES: RES: Possible incubation?
> To: "'Andre Dantas Rocha'" , "'Commons
Developers List'"
> Date: Wednesday, April 8, 2009, 1:49 PM
> I agree with you in some points.
> Maybe it is better to return inside
> exceptions to the caller instead of catch them locally.
>
> The problem, for me, remains in this part: "see if we have
> a method to
> handle such an exception by checking if a method
> handleIllegalArgumentException exists"
>
> I believe that implement an
> handleIllegalArgumentException() method it's not
> the best solution for the problem. Maybe the best strategy
> is to overload
> handle() method for handling exceptions of handler's
> responsibility. For
> example, Instead of handleIllegalArgumentException(),
> codify a
> handle(IllegalArgumentException e):
>
> public class MyHandler implements handler {
>public Throwable
> handle(IllegalArgumentException e, ...) {
> // specific code
>}
>
>public Throwable handle(Throwable t, ...)
> {
> return t;
>}
> }
>
> 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?
>
> Andre
>
>
> -Mensagem original-
> De: Gaurav Arora [mailto:gauravar...@codercorp.com]
>
> Enviada em: quarta-feira, 8 de abril de 2009 12:37
> Para: Commons Developers List
> Assunto: Re: RES: RES: Possible incubation?
>
> I agree with you that there is no elegant way to say what
> can and cannot
> be handled by the handler so what I suggest is let the
> handler decide what
> it can and cannot handle. Looking at the handler should
> give one a clear
> picture of what its equipped to handle.
>
> Here's what I mean with an example:
>
> @ExceptionHandler(MyHandler.class)
> public void foo() {
> try {
> doSomething();
> } catch (Exception ex) {
> handler.handle(ex);
> }
> }
>
> Assume the above method throws an
> IllegalArgumentException.
>
> In our handler:
> public Throwable handle(Exception e) {
> // get the type of exception
> // see if we have a method to handle such an
> exception by checking if
> a method handleIllegalArgumentException exists
> // if we don't simply return the exception
> back
> }
>
> This way there is no need to explicitly define what
> exceptions can and
> cannot be handled. What is not handled is simply thrown
> back to the
> caller. But what it does is provides a very clean caller in
> the sense that
> it has no actual exception handling code, just a single
> catchAll.
>
> I am not sure on what exceptions should be handled by the
> handle method
> itself. Asking the handler to handle all it's own
> exceptions, in a way,
> again asks you to duplicate the code, which is what Jeha is
> trying to
> remove. Otherwise, you'll need to define exception handlers
> for the
> handlers themselves which in my view can get tricky real
> fast.
>
> I don't think that the option of rethrowing should rest
> with the caller.
> What the caller is saying is that the handler will handle
> all it's
> exceptions and it itself knows nothing about what is going
> on. Asking the
> caller to handle rethrows sort of splits the responsibility
> between the
> two which again, is something that can get tricky.
>
> Gaurav
>
>
> > Hi Gurav,
> >
> > The weaving could be accomplished statically using
> ASM, BCEL, Javassist or
> > any similar tool. In my opinion, a bytecode library
> must be used only
> > during
> > compilation process; it's better (and cleaner) if the
> program does not
> > need
> > it to work.
> >
> > Personally, I think that attach handlers with specific
> exception types
> > could
> > be a problem when you have a method that throws
> exceptions of different
> > kinds. I don't think that it could be specified (in a
> elegant way) in
> > annotations. Maybe it preferable to let it more
> generic...
> >
> > I believe that the strategy of rethrowing an exc
RES: RES: RES: RES: Possible incubation?
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 problem.
Andre
-Mensagem original-
De: Gaurav Arora [mailto:gauravar...@codercorp.com]
Enviada em: sexta-feira, 10 de abril de 2009 09:00
Para: Commons Developers List
Assunto: Re: RES: RES: RES: Possible incubation?
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 would again cause extra code in the caller.
I just want to touch up on a point you mentioned in your other mail about
HandlerUtil.handle(). I personally would love to avoid such a call at all.
I think the entire framework should be as transparent as possible to avoid
unnecessary code. The annotation already provides metadata for a developer
to refer too so there isn't a need for an explicit call.
Gaurav
> I agree with you in some points. Maybe it is better to return inside
> exceptions to the caller instead of catch them locally.
>
> The problem, for me, remains in this part: "see if we have a method to
> handle such an exception by checking if a method
> handleIllegalArgumentException exists"
>
> I believe that implement an handleIllegalArgumentException() method it's
> not
> the best solution for the problem. Maybe the best strategy is to overload
> handle() method for handling exceptions of handler's responsibility. For
> example, Instead of handleIllegalArgumentException(), codify a
> handle(IllegalArgumentException e):
>
> public class MyHandler implements handler {
>public Throwable handle(IllegalArgumentException e, ...) {
> // specific code
>}
>
>public Throwable handle(Throwable t, ...) {
> return t;
>}
> }
>
> 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?
>
> Andre
>
>
> -Mensagem original-
> De: Gaurav Arora [mailto:gauravar...@codercorp.com]
> Enviada em: quarta-feira, 8 de abril de 2009 12:37
> Para: Commons Developers List
> Assunto: Re: RES: RES: Possible incubation?
>
> I agree with you that there is no elegant way to say what can and cannot
> be handled by the handler so what I suggest is let the handler decide what
> it can and cannot handle. Looking at the handler should give one a clear
> picture of what its equipped to handle.
>
> Here's what I mean with an example:
>
> @ExceptionHandler(MyHandler.class)
> public void foo() {
> try {
> doSomething();
> } catch (Exception ex) {
> handler.handle(ex);
> }
> }
>
> Assume the above method throws an IllegalArgumentException.
>
> In our handler:
> public Throwable handle(Exception e) {
> // get the type of exception
> // see if we have a method to handle such an exception by checking if
> a method handleIllegalArgumentException exists
> // if we don't simply return the exception back
> }
>
> This way there is no need to explicitly define what exceptions can and
> cannot be handled. What is not handled is simply thrown back to the
> caller. But what it does is provides a very clean caller in the sense that
> it has no actual exception handling code, just a single catchAll.
>
> I am not sure on what exceptions should be handled by the handle method
> itself. Asking the handler to handle all it's own exceptions, in a way,
> again asks you to duplicate the code, which is what Jeha is trying to
> remove. Otherwise, you'll need to define exception handlers for the
> handlers themselves which in my view can get tricky real fast.
>
> I don't think that the option of rethrowing should rest with the caller.
> What the caller is saying is that the handler will handle all it's
> exceptions and it itself knows nothing about what is going on. Asking the
> caller to handle rethrows sort of splits the responsibility between the
> two which again, is something that can get tricky.
>
> Gaurav
>
>
>> Hi Gurav,
>>
>> The weaving could be accomplished statically using ASM, BCEL, Javassist
>> or
>> any similar tool. In my opinion, a bytecode library must be used only
>> during
>> compilation process; it's better (and cleaner) if the program does not
>> need
>> it to work.
>>
>> Personally, I think that attach handlers with specific exception types
>> could
>> be a problem when you have a method that throws exceptions of different
>> kinds. I don't think that it could be specified (in a elegant way) in
>> annotations. Maybe it preferable to let it more generic...
>>
>> I believe that the strategy of rethrowing an exception or not must be
>> accomplished by
Re: RES: RES: RES: Possible incubation?
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 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 problem.
>
> Andre
>
> -Mensagem original-
> De: Gaurav Arora [mailto:gauravar...@codercorp.com]
> Enviada em: sexta-feira, 10 de abril de 2009 09:00
> Para: Commons Developers List
> Assunto: Re: RES: RES: RES: Possible incubation?
>
> 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 would again cause extra code in the caller.
>
> I just want to touch up on a point you mentioned in your other mail about
> HandlerUtil.handle(). I personally would love to avoid such a call at all.
> I think the entire framework should be as transparent as possible to avoid
> unnecessary code. The annotation already provides metadata for a developer
> to refer too so there isn't a need for an explicit call.
>
> Gaurav
>
> > I agree with you in some points. Maybe it is better to return inside
> > exceptions to the caller instead of catch them locally.
> >
> > The problem, for me, remains in this part: "see if we have a method to
> > handle such an exception by checking if a method
> > handleIllegalArgumentException exists"
> >
> > I believe that implement an handleIllegalArgumentException() method it's
> > not
> > the best solution for the problem. Maybe the best strategy is to overload
> > handle() method for handling exceptions of handler's responsibility. For
> > example, Instead of handleIllegalArgumentException(), codify a
> > handle(IllegalArgumentException e):
> >
> > public class MyHandler implements handler {
> >public Throwable handle(IllegalArgumentException e, ...) {
> > // specific code
> >}
> >
> >public Throwable handle(Throwable t, ...) {
> > return t;
> >}
> > }
> >
> > 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?
> >
> > Andre
> >
> >
> > -Mensagem original-
> > De: Gaurav Arora [mailto:gauravar...@codercorp.com]
> > Enviada em: quarta-feira, 8 de abril de 2009 12:37
> > Para: Commons Developers List
> > Assunto: Re: RES: RES: Possible incubation?
> >
> > I agree with you that there is no elegant way to say what can and cannot
> > be handled by the handler so what I suggest is let the handler decide
> what
> > it can and cannot handle. Looking at the handler should give one a clear
> > picture of what its equipped to handle.
> >
> > Here's what I mean with an example:
> >
> > @ExceptionHandler(MyHandler.class)
> > public void foo() {
> > try {
> > doSomething();
> > } catch (Exception ex) {
> > handler.handle(ex);
> > }
> > }
> >
> > Assume the above method throws an IllegalArgumentException.
> >
> > In our handler:
> > public Throwable handle(Exception e) {
> > // get the type of exception
> > // see if we have a method to handle such an exception by checking if
> > a method handleIllegalArgumentException exists
> > // if we don't simply return the exception back
> > }
> >
> > This way there is no need to explicitly define what exceptions can and
> > cannot be handled. What is not handled is simply thrown back to the
> > caller. But what it does is provides a very clean caller in the sense
> that
> > it has no actual exception handling code, just a single catchAll.
> >
> > I am not sure on what exceptions should be handled by the handle method
> > itself. Asking the handler to handle all it's own exceptions, in a way,
> > again asks you to duplicate the code, which is what Jeha is trying to
> > remove. Otherwise, you'll need to define exception handlers for the
> > handlers themselves which in my view can get tricky real fast.
> >
> > I don't think that the option of rethrowing should rest with the caller.
> > What the caller is saying is that the handler will handle all it's
> > exceptions and it itself knows nothing about what is going on. Asking the
> > caller to handle rethrows sort of splits the responsibility between the
> > two which again, is something that can get tricky.
> >
> > Gaurav
> >
> >
> >> Hi Gurav,
> >>
> >> The weaving could be accomplished statically using ASM, BCEL, Javassist
> >> or
> >> any similar tool. In my opinion, a bytecode library must be used only
> >> during
> >> compilation process; it's better (and cleaner) if the program
Re: RES: RES: RES: Possible incubation?
: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 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 problem.
>>
>> Andre
>>
>> -Mensagem original-
>> De: Gaurav Arora [mailto:gauravar...@codercorp.com]
>> Enviada em: sexta-feira, 10 de abril de 2009 09:00
>> Para: Commons Developers List
>> Assunto: Re: RES: RES: RES: Possible incubation?
>>
>> 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 would again cause extra code in the caller.
>>
>> I just want to touch up on a point you mentioned in your other mail about
>> HandlerUtil.handle(). I personally would love to avoid such a call at all.
>> I think the entire framework should be as transparent as possible to avoid
>> unnecessary code. The annotation already provides metadata for a developer
>> to refer too so there isn't a need for an explicit call.
>>
>> Gaurav
>>
>> > I agree with you in some points. Maybe it is better to return inside
>> > exceptions to the caller instead of catch them locally.
>> >
>> > The problem, for me, remains in this part: "see if we have a method to
>> > handle such an exception by checking if a method
>> > handleIllegalArgumentException exists"
>> >
>> > I believe that implement an handleIllegalArgumentException() method it's
>> > not
>> > the best solution for the problem. Maybe the best strategy is to
>> overload
>> > handle() method for handling exceptions of handler's responsibility. For
>> > example, Instead of handleIllegalArgumentException(), codify a
>> > handle(IllegalArgumentException e):
>> >
>> > public class MyHandler implements handler {
>> >public Throwable handle(IllegalArgumentException e, ...) {
>> > // specific code
>> >}
>> >
>> >public Throwable handle(Throwable t, ...) {
>> > return t;
>> >}
>> > }
>> >
>> > 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?
>> >
>> > Andre
>> >
>> >
>> > -Mensagem original-
>> > De: Gaurav Arora [mailto:gauravar...@codercorp.com]
>> > Enviada em: quarta-feira, 8 de abril de 2009 12:37
>> > Para: Commons Developers List
>> > Assunto: Re: RES: RES: Possible incubation?
>> >
>> > I agree with you that there is no elegant way to say what can and cannot
>> > be handled by the handler so what I suggest is let the handler decide
>> what
>> > it can and cannot handle. Looking at the handler should give one a clear
>> > picture of what its equipped to handle.
>> >
>> > Here's what I mean with an example:
>> >
>> > @ExceptionHandler(MyHandler.class)
>> > public void foo() {
>> > try {
>> > doSomething();
>> > } catch (Exception ex) {
>> > handler.handle(ex);
>> > }
>> > }
>> >
>> > Assume the above method throws an IllegalArgumentException.
>> >
>> > In our handler:
>> > public Throwable handle(Exception e) {
>> > // get the type of exception
>> > // see if we have a method to handle such an exception by checking
>> if
>> > a method handleIllegalArgumentException exists
>> > // if we don't simply return the exception back
>> > }
>> >
>> > This way there is no need to explicitly define what exceptions can and
>> > cannot be handled. What is not handled is simply thrown back to the
>> > caller. But what it does is provides a very clean caller in the sense
>> that
>> > it has no actual exception handling code, just a single catchAll.
>> >
>> > I am not sure on what exceptions should be handled by the handle method
>> > itself. Asking the handler to handle all it's own exceptions, in a way,
>> > again asks you to duplicate the code, which is what Jeha is trying to
>> > remove. Otherwise, you'll need to define exception handlers for the
>> > handlers themselves which in my view can get tricky real fast.
>> >
>> > I don't think that the option of rethrowing should rest with the caller.
>> > What the caller is saying is that the handler will handle all it's
>> > exceptions and it itself knows nothing about what is going on. Asking
>> the
>> > caller to handle rethrows sort of splits the responsibility between the
>> > two which again, is something that can get tricky.
>> >
>> > Gaurav
>> >
>> >
>> >> Hi Gurav,
>>
[Configuration] experimental branch uses java.util.logging?
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 some reason for moving away from commons-logging I'd be happy to do the work to migrate to SLF4J. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
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, if there is some reason for moving away from commons-logging I'd be happy to do the work to migrate to SLF4J. Ralph This change was made by Emmanuel, IIRC for the reason of getting rid of a dependency. Personally I was not too happy with this change either. IMHO libraries should use logging facades rather than forcing applications to use specific logging tools. So we seem to agree in this point. About the abstraction to use I am a bit indifferent. There is this point of eating our own dog food (i.e. commons-logging). But if you prefer SLF4J (I haven't used it myself), I am not opposed to moving to it. Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
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 commons-logging is better than using j.u.l directly. As I said, if there is some reason for moving away from commons-logging I'd be happy to do the work to migrate to SLF4J. Ralph This change was made by Emmanuel, IIRC for the reason of getting rid of a dependency. Personally I was not too happy with this change either. IMHO libraries should use logging facades rather than forcing applications to use specific logging tools. So we seem to agree in this point. About the abstraction to use I am a bit indifferent. There is this point of eating our own dog food (i.e. commons-logging). But if you prefer SLF4J (I haven't used it myself), I am not opposed to moving to it. Glad to hear that we are on the same page. If we continue to use commons-logging I would want to add a bunch of enhancements to it that SLF4J already has. I suspect that this would require a new branch of commons logging and I'd probably want the minimum version to be Java 5. Since I'm only one guy and stretched very thin I'm not sure when I could get to that. But I really would like to. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
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 SLF4J, using commons-logging is better than using j.u.l directly. As I said, if there is some reason for moving away from commons-logging I'd be happy to do the work to migrate to SLF4J. Ralph This change was made by Emmanuel, IIRC for the reason of getting rid of a dependency. Personally I was not too happy with this change either. IMHO libraries should use logging facades rather than forcing applications to use specific logging tools. So we seem to agree in this point. About the abstraction to use I am a bit indifferent. There is this point of eating our own dog food (i.e. commons-logging). But if you prefer SLF4J (I haven't used it myself), I am not opposed to moving to it. Glad to hear that we are on the same page. If we continue to use commons-logging I would want to add a bunch of enhancements to it that SLF4J already has. I suspect that this would require a new branch of commons logging and I'd probably want the minimum version to be Java 5. Since I'm only one guy and stretched very thin I'm not sure when I could get to that. But I really would like to. There should be a couple of people around here who are interested in commons-logging. So it may make sense to start a new thread to discuss the enhancements you have in mind. Maybe that gives some momentum to this component. Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
--- 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: > >>> 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 some reason for moving away from > commons-logging I'd be happy to do the work to migrate to > SLF4J. > >>> Ralph > >> This change was made by Emmanuel, IIRC for the > reason of getting rid of a dependency. Personally I was not > too happy with this change either. IMHO libraries should use > logging facades rather than forcing applications to use > specific logging tools. So we seem to agree in this point. > >> > >> About the abstraction to use I am a bit > indifferent. There is this point of eating our own dog food > (i.e. commons-logging). But if you prefer SLF4J (I haven't > used it myself), I am not opposed to moving to it. > > > > Glad to hear that we are on the same page. > > > > If we continue to use commons-logging I would want to > add a bunch of enhancements to it that SLF4J already has. I > suspect that this would require a new branch of commons > logging and I'd probably want the minimum version to be Java > 5. Since I'm only one guy and stretched very thin I'm not > sure when I could get to that. But I really would like to. > > > There should be a couple of people around here who are > interested in commons-logging. So it may make sense to start > a new thread to discuss the enhancements you have in mind. > Maybe that gives some momentum to this component. > 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? No slight to those who have worked on [logging] in the past, but if their interests have moved on while Ceki continues to focus on logging, why not simply leave the domain to him? There is an established path for interop, so this shouldn't keep anybody up at night IMHO. If we were interested in having [logging]'s API differ significantly from that of slf4j it'd be a different story, but this simply sounds like NIH, which is not what I think the ASF is about. -Matt > Oliver > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[compress] TarArchiveInputStream weird method
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 you have other opinions, let me know and I will revert :-) Best, Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Logging] was Re: [Configuration] experimental branch uses java.util.logging?
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? No slight to those who have worked on [logging] in the past, but if their interests have moved on while Ceki continues to focus on logging, why not simply leave the domain to him? There is an established path for interop, so this shouldn't keep anybody up at night IMHO. If we were interested in having [logging]'s API differ significantly from that of slf4j it'd be a different story, but this simply sounds like NIH, which is not what I think the ASF is about. Obviously, I don't have too many technical issues with using SLF4J or I wouldn't have suggested it. Here are some random thoughts. 1. Ceki has been doing this for years and has learned an awful lot about logging. 2. The development community around SLF4J is fairly small - but it is probably larger and more active than that around commons-logging. 3. Ceki maintains fairly close control over SLF4J and Logback. I have commit rights to slf4j-ext and the web site but not the core. I'm not sure who besides Ceki does. 4. Even though he maintains close control, Ceki is fairly open to suggestions. The only 'troubles' I've experienced have been when he has been unavailable. 5. I've asked Ceki about bringing SLF4J and/or Logback to Apache. He seems quite happy with the way things are. All that really doesn't say much. The primary difference is simply around how the community is run. I don't see any danger that the SLF4J community is going to die any time soon, so I don't think we should really care that it isn't run exactly like an Apache project. As you pointed out, the license is compatible and other Apache projects are already using it. The real question is, if one was to create a commons logging 2.0 what would it be and would that be a significant improvement over SLF4J and the existing commons logging? Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: SSH Implementation - IDEA and seeking Suggestions.
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 (user+password, user+interactive, certificate, etc?). Something like this: SSHConnectionFactory factory = new SSHConnectionFactory(); factory.setConnectionTimeout(...); SSHConnection connection = factory.connect(host, port); connection.auth(username, password); OR connection.auth(certificate); ConsoleSession session = connection.openConsoleSession(80, 24, 800, 600, 0); ... 2) Still want to consider implementing SSH as part of distinguish library, not as part of commons-net. Because of internal regulations i would not be able to use any crypto-related libraries in some projects. We are using commons-net already, and it will be pain to get rid of it if it will start to contain SSH-related stuff. Best regards, Sergey On Wed, Apr 8, 2009 at 2:39 PM, Vinod Kumar Badhavat < vinod.ofgov...@gmail.com> wrote: > SSHConnect -- Sergey Vladimirov
