commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject [proxy] Overriding Specific Methods Support...
Date Wed, 05 Nov 2008 10:48:18 GMT
>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


Mime
View raw message