PDA

View Full Version : Common Attributes has to be written in impl class


swisswheel
Nov 23rd, 2004, 08:17 AM
Hi,

I'm using transactions with "Common Attributes" and beans will be proxied by using "DefaultAdvisorAutoProxyCreator". Now I've got the problem, that I have to write attributes in implementation class and not on its interface. Do I have a possibility to realize that I can define the attibutes in interfaces and not in implementation classes?

Cheers,
Martin

Rod Johnson
Nov 23rd, 2004, 10:28 AM
The CommonsAttributes implementation of our Attributes interface doesn't make any changes to the treatment of inheritance that Commons Attributes does itself. However, if you do want to fallback to interfaces, you could easily implement your own form of that facade and plug it in.

You could look at Spring's AbstractFallbackTransactionAttributeSource as a guide: this does fall back to interface attributes if necessary.

In general I think of transaction attributes as being naturally on implementations. But I guess with other kinds of attributes you may have different concepts.

Btw Tiger annotation support is already in the "samples" module in CVS and will be released in 1.2.

Rgds
Rod

swisswheel
Nov 24th, 2004, 05:00 AM
Now I've adapted the method computeTransactionAttribute from class AbstractFallbackTransactionAttributeSource like the following:


private TransactionAttribute computeTransactionAttribute(Method method,
Class targetClass) {
// The method may be on an interface, but we need attributes from the
// target class. The AopUtils class provides a convenience method for
// this. If the target class is null, the method will be unchanged.
Method specificMethod = AopUtils.getMostSpecificMethod(method,
targetClass);

// First try is the method in the target class
TransactionAttribute txAtt = findTransactionAttribute(findAllAttributes(specifi cMethod));
if (txAtt != null)
return txAtt;

// Second try is the transaction attribute on the target class
txAtt = findTransactionAttribute(findAllAttributes(specifi cMethod
.getDeclaringClass()));
if (txAtt != null)
return txAtt;

if (specificMethod != method) {
// Fallback is to look at the original method
txAtt = findTransactionAttribute(findAllAttributes(method) );
if (txAtt != null)
return txAtt;
// Fallback is the class of the original method
txAtt = findTransactionAttribute(findAllAttributes(method
.getDeclaringClass()));
if (txAtt != null)
return txAtt;
}

Class[] interfaces = method.getDeclaringClass().getInterfaces();
if (AopUtils.methodIsOnOneOfTheseInterfaces(method , interfaces)) {
Method interfaceMethod = null;
for (int i = 0; interfaceMethod == null && i < interfaces.length; i++) {
try {
interfaceMethod = interfaces[i].getMethod(method
.getName(), method.getParameterTypes());
} catch (SecurityException e) {
} catch (NoSuchMethodException e) {
}
}

if (interfaceMethod != null) {
// Fallback is to look at the declared method on interface
txAtt = findTransactionAttribute(findAllAttributes(interfa ceMethod));
if (txAtt != null)
return txAtt;
// Last fallback is the interface of the method
return findTransactionAttribute(findAllAttributes(interfa ceMethod
.getDeclaringClass()));
}
}
return null;
}


With the help of this modification it is also possible to define Attributes only in interfaces. I think this would be nice to have this modification in class AbstractFallbackTransactionAttributeSource. What's your opinion?

Cheers,
Martin