>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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
