commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <>
Subject RE: [proxy] Commons-Lang Dependency...
Date Fri, 09 Sep 2005 03:04:07 GMT
That particular class (ExecutorMethodInterceptor) could depend upon JCL,
since it really does need to be able to indicate that failure (a void method
executed in another thread threw an exception) somehow.  I don't mind
including classes in proxy that would require a runtime dependency, but the
core API shouldn't cause too many.  So, I really could re-introduce that
code back into ExecutorMethodInterceptor and I very well may do that.
Again, I'm glad proxy is still in the sandbox! :-)

-----Original Message-----
From: Rahul Akolkar [] 
Sent: Thursday, September 08, 2005 8:53 PM
To: Jakarta Commons Developers List
Subject: Re: [proxy] Commons-Lang Dependency...

On 9/8/05, James Carman <> wrote:
> Thank you for the advice, guys!  I copied the getAllInterfaces() method
> to my ProxyUtils class and documented that I "borrowed" it from Jakarta
> Commons Lang.  Then, I removed my dependency on Jakarta Commons Logging,
> because all I was doing was printing out informational messages for
> debugging purposes.  

I'm sure you gave enough thought before removing the JCL bits, but my
2c -- the larger the black boxes of magic, the more chances are that
users will be bitten by the absence of logging. If proxy is broad and
shallow (Stephen's term from another thread), you can probably get
away with it.

Just saw this in r279571:

-      getLog().error( "Method invocation threw an exception.", t );
+      // What to do here?  I can't convey the failure back to the caller.

which prompted me to participate here. For completion, I have no
understanding (yet) of that piece of code, but this remark is meant to
transcend that ;-)


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message