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 [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> wrote: > Thank you for the advice, guys! I copied the getAllInterfaces() method over > 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. <snip/> 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: <snap/> - getLog().error( "Method invocation threw an exception.", t ); + // What to do here? I can't convey the failure back to the caller. <snip/> 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 ;-) -Rahul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
