Results 1 to 3 of 3

Thread: Common Attributes has to be written in impl class

Hybrid View

  1. #1
    Join Date
    Nov 2004
    Location
    Zurich [CH]
    Posts
    14

    Default Common Attributes has to be written in impl class

    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

  2. #2
    Join Date
    Aug 2004
    Location
    San Mateo, CA
    Posts
    1,265

    Default

    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
    Rod Johnson - GM, SpringSource Division, VMware
    http://www.springsource.com
    Spring From the Source

  3. #3
    Join Date
    Nov 2004
    Location
    Zurich [CH]
    Posts
    14

    Default Method computeTransactionAttribute adapted

    Now I've adapted the method computeTransactionAttribute from class AbstractFallbackTransactionAttributeSource like the following:

    Code:
        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(specificMethod));
            if (txAtt != null)
                return txAtt;
    
            // Second try is the transaction attribute on the target class
            txAtt = findTransactionAttribute(findAllAttributes(specificMethod
                    .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 &#40;int i = 0; interfaceMethod == null && i < interfaces.length; i++&#41; &#123;
                    try &#123;
                        interfaceMethod = interfaces&#91;i&#93;.getMethod&#40;method
                                .getName&#40;&#41;, method.getParameterTypes&#40;&#41;&#41;;
                    &#125; catch &#40;SecurityException e&#41; &#123;
                    &#125; catch &#40;NoSuchMethodException e&#41; &#123;
                    &#125;
                &#125;
    
                if &#40;interfaceMethod != null&#41; &#123;
                    // Fallback is to look at the declared method on interface
                    txAtt = findTransactionAttribute&#40;findAllAttributes&#40;interfaceMethod&#41;&#41;;
                    if &#40;txAtt != null&#41;
                        return txAtt;
                    // Last fallback is the interface of the method
                    return findTransactionAttribute&#40;findAllAttributes&#40;interfaceMethod
                            .getDeclaringClass&#40;&#41;&#41;&#41;;
                &#125;
            &#125;
            return null;
        &#125;
    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

Similar Threads

  1. Order of Bean definitions matters?
    By cfuser in forum Container
    Replies: 2
    Last Post: Oct 21st, 2005, 10:29 AM
  2. Spring container fails with no exception
    By naor in forum Container
    Replies: 9
    Last Post: Oct 1st, 2005, 03:39 PM
  3. EHCaching Hibernate
    By dencamel in forum Data
    Replies: 3
    Last Post: Sep 6th, 2005, 09:03 PM
  4. Replies: 3
    Last Post: Sep 4th, 2005, 11:11 PM
  5. Stack Overflow
    By rayho222 in forum Container
    Replies: 6
    Last Post: May 17th, 2005, 03:42 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •