Sorry for the cross post, I think this email is more appropriate for
the dev list. I appreciate any input (if this makes sense, I'm can
contribute code for this)
I was trying to figure a simple way to use attributes for AOP in 1.4
that doesn't require an extra compilation step, and I came up with a
dynamic approach:
In my spring configuration, I just set some attributes like this:
<bean id=3D"exampleService"
class=3D"com.foo.ExampleCachingService">
<property name=3D"methodAttributes"><map>
<entry key=3D"getFoo"><list>
<value>org.wanghy.cache.interceptor.caching.Cached("test")</valu=
e>
<value>...interceptor.DefaultTransactionAttribute()</value>
</list></entry>
</map></property>
</bean>
I have a BaseDynamicAttributedBean, that initializes the attributes:
public void setMethodAttributes(Map methodAttributes) {
this.methodAttributes =3D methodAttributes;
}
public void afterPropertiesSet() throws Exception {
DynamicAttributes.initAttributes(this.getClass(), methodAttributes);
}
The implementation of DynamicAttributes (which implements
org.springframework.metadata.Attributes) uses an java interpreter to
evaluate the attribute definition (right now I'm using Groovy, but it
could use anything like Janino or BeanShell). I'm also planning on
adding some error checking, like making sure that there isn't more
than one bean trying to set attributes for a given class, making sure
method names aren't ambigous, etc.
I had two reasons for wanting to do this: 1) using java 1.5 isn't an
option on the project I'm working on, and we wanted to avoid the
additional compilation step of using commons attributes. 2) there's a
percieved desire/preference in my project to be able to configure AOP
in XML, and I think that the other ways to configure interceptors in
XML is kind of confusing and verbose.
I ran some tests and it seems to work fine. My question is, does
anyone see any potential pitfalls with this approach?
thanks,
Otto
|
