Announcement Announcement Module
Collapse
No announcement yet.
How to have own attributes in MethodInvocation? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to have own attributes in MethodInvocation?

    Is there a way to enhance the MethodInvocation class by own attributes?
    Background is, that I need to propagate additional information with my MethodInvocation along the interceptor chain (e.g. some sort of SecurityContext). However, the invocation object is an unknown subclass of MethodInvocation and is instantiated by the Spring-Container, so I cannot directly use an own implementation of this interface which contains the additional attributes... Is there any convenient hook...?

    Thanks,

    Sven

  • #2
    I'd rather use a ThreadLocal to propagate additional information. This way, you explicitly model the relation and you can see where the contextual information is used.

    regards,
    Alef

    Comment


    • #3
      Re: How to have own attributes in MethodInvocation?

      Originally posted by sven.bauer
      Is there any convenient hook...?
      As it's security-related, take a look at Acegi Security. It provides a ContextHolder (a ThreadLocal) and manages storage of its contents between subsequent web requests.

      Comment


      • #4
        Originally posted by Alef Arendsen
        I'd rather use a ThreadLocal to propagate additional information.
        The reason why I want to extend the invocation object is to be able to pass some information in a cross-cutting manner, even with SLSB-calls. In this case, ThreadLocal does not seem to be the best way because it simply ends at process boundaries. It would be more convenient to simply forward the invocation object via an invoke()-call on the SLSB...

        Additionally, although I like ThreadLocals very much, it is still a means of using sort of "global variables" and therefore should only be used when really "global" information (global to the thread) is affected...

        However, I don't mind using it, if there is no other solution...

        Sven

        Comment


        • #5
          Why is it better to use ThreadLocal

          Originally posted by Alef Arendsen
          This way, you explicitly model the relation and you can see where the contextual information is used.
          I am sorry, I do not understand the argument.

          How is the relationship (between which entities) modeled more explicit?

          And why am I able to better see where the contextual information is used? If I could enhance Invocation (or create my own implementation), I could see where the information is used as well as when using ThreadLocal.

          ThreadLocal introduces a kind of global variables, which I try to avoid where possible.

          Comment


          • #6
            Creating the context pattern is easy when wrapping a ThreadLocal in a bean and wiring up the bean wherever you need it. That's what I meant with seeing where the ThreadLocal is used.

            Yes, the danger of using a ThreadLocal is that you're creating global variables, but that's only the case when using them in a static fashion.

            Think of something like this:

            Code:
            // somewhat like the contextholder Acegi uses
            public void Context {
              private ThreadLocal tl = new ThreadLocal();
              public void setContextObject(ContextObject o) {
                this.tl.set(o);
              }
            
              public void reset() {
                this.tl.set(null);
              }
            }
            
            public class BusinessObject {
              private Context context;
              public void setContext(Context c) { .. }
            }
            
            <bean class="BusinessObject">
              <property name="context"><ref bean="context"/></property>
            </bean>
            
            <bean id="context" class="Context"/>
            This way, you (have to) wire up the context whereever you need it and it's clear that the business object is using it.

            regards,
            Alef

            Comment


            • #7
              Originally posted by Alef Arendsen
              Creating the context pattern is easy when wrapping a ThreadLocal in a bean and wiring up the bean wherever you need it.
              Thanks Alef,

              that's a great way of managing ThreadLocals!

              However, my original intent was to make a remote call at the end of my interceptor chain and pass the invocation object as an argument. This sort of extends my interceptor chain to another process, which gives me the ability to pass context-parameters to an EJB (SLSB) - if I could add them to my invocation object!

              Cheers,
              Sven

              Comment


              • #8
                See also http://forum.springframework.org/sho...5222#post45222. Since 1.2.6 there is a metadata map on Spring AOP's ReflectiveMethodInvocation.

                Rgds
                Rod

                Comment

                Working...
                X