Announcement Announcement Module
Collapse
No announcement yet.
<aop:config> vs BeanNameAutoproxyCreator compatibility Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • <aop:config> vs BeanNameAutoproxyCreator compatibility

    Hi, Spring documentation states a warning message:
    The <aop:config> style of configuration makes heavy use of Spring's auto-proxying mechanism. This can cause issues (such as advice not being woven) if you are already using explicit auto-proxying via the use of BeanNameAutoProxyCreator or suchlike. The recommended usage pattern is to use either just the <aop:config> style, or just the AutoProxyCreator style.

    My questions are:
    Does the documentation warning mean that <aop:aspectj-autoproxy> in combination with <aop:config> is considered dangerous?
    Could someone explain it a bit more or point out an example where a conflict can occur (advice not being woven)? It works fine in my project. From technical point of view, there is a proxy created by <aop config> (Advised.getAdvisors returns aop config advisors) wrapped by another proxy created by BeanNameAutoProxyCreator (Adviced.getAdvisors returns its interceptors).

  • #2
    You can end-up in proxying a proxy when using classbased proxies this can be painful (in general those classes are final). Also spring also expects, in some places, only 1 level of proxying going on (to retrieve the actual class) and with a double proxy this fails.

    I always advice to use either one but to avoid using both (in general it leads to more trouble then it's worth).

    Comment


    • #3
      Thank you for the reasonable explanation.
      Now I am curious why Spring does not merge these aspects to one proxy. Instead of proxying an existing proxy, it is possible (at least by the Spring proxy API - Advised#addAdvice()) to add an advice to the existing proxy. This sounds natural to me since both types of aspect definitions use the same autoproxy facility.

      Comment


      • #4
        The proxy doesn't have to be a spring based proxy next to that the 'older' proxying is working a little different (in regards to matching when/where to execute advices/interceptors) as compared to AspectJ so those are different.

        There where several issues opened for this but this isn't resolved (also in general people don't mix different strategies).

        Comment

        Working...
        X