|
From: Rod J. <rod...@in...> - 2003-10-10 18:09:02
|
> What I'm most excited about is the BeanPostProcessor hook. I expect that
to be very powerful, as already indicated by the respective test case in
StaticApplicationContextSuite. Another example that I've prototyped is the
following (not yet in CVS):
> public class AutoProxyCreator implements BeanPostProcessor {
> private List beanNames;
> private Interceptor[] interceptors;
>
> public void setBeanNames(String[] beanNames) {
> this.beanNames = Arrays.asList(beanNames);
> }
>
> public void setInterceptors(Interceptor[] interceptors) {
> this.interceptors = interceptors;
> }
>
> public Object postProcessBean(Object bean, String name,
RootBeanDefinition definition) {
> if (this.beanNames != null && this.beanNames.contains(name)) {
> ProxyFactory proxyFactory = new ProxyFactory();
> for (int i = 0; i < this.interceptors.length; i++) {
> proxyFactory.addInterceptor(this.interceptors[i]);
> }
> proxyFactory.addInterceptor(new InvokerInterceptor(bean));
> return proxyFactory.getProxy();
> }
> else {
> return bean;
> }
> }
> }
> Of course, source-level metadata would allow for just 1 BeanPostProcessor
plus the 10 target beans (11 beans in total), with the transaction
attributes being kept with the respective methods in the source code. This
would just get rid of 1 bean but of a pretty bloated one: the
TransactionInterceptor definition with its centralized transaction
attributes for the whole app.
This _is_ exciting.
Source-level metadata might also mean we wouldn't need to know the names of
the transactional beans. We sould simply need to install a BeanPostProcessor
that would look up metadata. It could work with arbitrary attributes,
depending on registered "attribute scanners".
Combined with good metadata support, I think we can match the ease of use of
.NET for enterprise services in M3. I have always seen this as the killer
application for Spring AOP.
Regards,
Rod
|