[proxy] Overriding Specific Methods Support...

[James Carman <ja...@carmanconsulting.com>]

>From another thread, Simon Kitching wrote:
>
>The decorator pattern is hugely useful. In particular, you can apply a
>decorator to an existing object (eg something returned by a library),
>which you cannot achieve by subclassing something. Even when it is your
>own code that is creating the actual object instance, a decorator is
>sometimes a more elegant approach than subclassing anyway.

Commons proxy already supports "decorating" an object using
"interceptors" (and provides a bridging class for AOP alliance-based
interceptors).  What I'm talking about adding support for is being
able to programmatically say "if this method comes in, use this
invoker instead."

>Having commons-proxy provide a way to proxy just specific methods would
>be nice, although not critical IMO. Proxying a specific method or
>methods can of course be built on top of a generic proxy API simply by:
> if (method.name == "foo") {
>   // do something
> } else {
>   method.invoke(proxy, args); // just forward the call on to the
>original object
> }
>but this is a little ugly.

I agree this is ugly.  That's why I'm proposing that perhaps we can
build in first-class support for this pattern (if it's deemed
useful/common enough).

>Having commons-proxy support running AOP Advices for specific methods
>while passing the others through automatically would be nice. However
>the standard "pointcut" language for specifying which methods to match
>is rather ugly and complex. And turning commons-proxy into a full AOP
>library supporting the org.aopalliance.aop.* APIs
>(http://aopalliance.sourceforge.net/) would be a big job. I presume
>you're aware that springframework.org includes extensive AOP support
>based on the aopalliance APIs?

Proxy has the concept of a MethodFilter that you can use to filter out
methods that you don't want proxied when you're using Interceptors.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [proxy] Overriding Specific Methods Support...

[James Carman <ja...@carmanconsulting.com>]

On Wed, Nov 5, 2008 at 5:48 AM, James Carman <ja...@carmanconsulting.com> wrote:
>>Having commons-proxy support running AOP Advices for specific methods
>>while passing the others through automatically would be nice. However
>>the standard "pointcut" language for specifying which methods to match
>>is rather ugly and complex. And turning commons-proxy into a full AOP
>>library supporting the org.aopalliance.aop.* APIs
>>(http://aopalliance.sourceforge.net/) would be a big job. I presume
>>you're aware that springframework.org includes extensive AOP support
>>based on the aopalliance APIs?
>
> Proxy has the concept of a MethodFilter that you can use to filter out
> methods that you don't want proxied when you're using Interceptors.
>

Oh, and yes I'm well aware of Spring's AOP support.  Commons Proxy is
written for folks who don't want to have to use Spring to get dynamic
proxies if they don't want to (or for Spring itself to use rather than
writing their own proxying logic).  Proxy is written for any framework
that needs dynamic proxying and they don't want to have to monkey with
all of the crazy logic necessary for wiring everything together.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org