Announcement Announcement Module
Collapse
No announcement yet.
Mixing proxying mechanisms (SPR-3459) Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mixing proxying mechanisms (SPR-3459)

    Hello,

    Please consider SPR-3459, especially Juergen's comments at the bottom. I think I found Rick's update to the documentation here, but it hasn't made its way to the public docs yet.

    Basically, the gist is that you are can only have one kind of proxy (either JDK/interface-based or CGLIB-based) for all the spring-aop in your app. You can't have JDK-based proxies for one aop:config and CGLIB-based for the other. More precisely, if you use CGLIB-based proxies for any advice, it will be used for all advice.

    OK, so what if my desire is not to use the same proxying mechanism for all of the AOP in my app?

    We have a JSF (MyFaces) app, and I'm using spring-aop to catch exceptions from the action methods on my backing bean. The action methods in my backing beans are not defined in any interfaces. So, I must use CGLIB-based proxies for my exceptionHandlerAdvice.

    We are also using Spring's transaction management, and of course the methods that I want wrapped in transactions are defined in my DAO interfaces. For this, I would prefer to use JDK/interface-based proxies, because it's better (see the bullets here), and why shouldn't I, since the methods I want to interface are defined in interfaces?

    Further, my DAOs extend NamedParameterJdbcDaoSupport. So, if I use CGLIB proxies for them, I must to either tolerate warnings in my logs that result from attempts to proxy final methods that I didn't write, or do acrobatics in my spring config to avoid the warnings.

    For the sake of example:

    Code:
            <aop:config proxy-target-class="false">
                    <aop:advisor
                            pointcut="execution(* *..*JdbcDao.*(..))"
                            advice-ref="txAdvice"
                            order="1"/>
            </aop:config>
    
            <aop:config proxy-target-class="true">
                    <aop:advisor
                            pointcut="execution(* *..*BackingBean.*Action(..))"
                            advice-ref="exceptionHandlerAdvice"
                            order="2"  />
            </aop:config>
    My experience with this configuration is in line with Juergen's comments in the Jira - CGLIB-based proxies are used for the transactions.

    So - what is the reason that this is the intended behavior? Is there any workaround that will allow me to use both proxy types?

  • #2
    Hi fudster

    Yeah you found the correct section in the reference docs that I made.

    Originally posted by fudster View Post
    OK, so what if my desire is not to use the same proxying mechanism for all of the AOP in my app?
    Well, right now you are stuck... it's an all or nothing proposition at the moment, which is a shame.

    Originally posted by fudster View Post
    So - what is the reason that this is the intended behavior?
    As I understand it this is the intended behaviour because it would be a great amount of work to change the Spring internals to accommodate this. Spring really should be able to support the scenario that you describe... however, that is the way it is for now. if I were you I'd actually raise a JIRA issue and ask for this to be implemented as an 'Improvement'. (In fact I might do it myself next week if you don't because I agree with you that this isn't a great situation.)

    Originally posted by fudster View Post
    Is there any workaround that will allow me to use both proxy types?
    As regards a workaround (hack really), you could do this... please don't quote me as having suggested this because it is really hacky. It's actually not my own idea, I heard it from the mother of the girl who works in the local butchers shop who evidently heard it from some guy standing on a street corner in Sheboygan, Idaho who apparently sells weiner-dog-art stickers for a living. Here is the hack... you should be able to create distinct ApplicationContexts, assemble a hierarchy of such contexts, and each context should be able to use and apply it's own specific proxying mechanism; so for example, you could create one ApplicationContext composed of beans that used CGLIB proxying, and another ApplicationContext composed of beans that used JDK proxying. Apologies if you are recoiling in horror at the thought of me suggesting that - I did say it was a hacky workaround, and it means you need to physically partition your Spring configuration files upfront

    Cheers
    Rick

    Comment


    • #3
      Hey Rick, thanks for your prompt reply!

      if I were you I'd actually raise a JIRA issue and ask for this to be implemented as an 'Improvement'. (In fact I might do it myself next week if you don't because I agree with you that this isn't a great situation.)
      OK... Are you saying that if a JIRA issue is raised as an Improvement, that it will be treated differently than 3459 was?

      (BTW please don't hesitate to raise the JIRA issue in my stead)

      As far as the workaround goes - I think I'll pass on the multiple contexts. But if you happen to see weiner-dog-art-sticker-guy, tell him I'd like to hear some anecdotes from him!

      For the meanwhile, as far as I've been able to determine, there should be no functional impact on my application. The CGLIB error I'm getting from final methods on NamedParameterJdbcDaoSupport are annoying, but I'll probably just tune the logging.

      Comment


      • #4
        Hiya

        Done, see SPR-3665, and watch it if you want to be notified of updates.

        Cheers
        Rick

        Comment


        • #5
          Thanks Rick! I will definitely be watching that ticket.

          Comment


          • #6
            I have a similar issue w/ JAX-WS, but unlike fudster mine is really keeping me from progressing (see http://forum.springframework.org/showthread.php?t=44129).

            The problem is that JAX-WS uses JDK proxies (which are final) for the WebService client, but wants to see my naked WebService Impl class (for they contain annotations).

            (@fudster: Fully ACK on the log thing being totally disturbing. :-))

            Comment

            Working...
            X