Announcement Announcement Module
No announcement yet.
Wormhole pattern in spring ? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Wormhole pattern in spring ?

    Hi ,

    Can Wormhole Pattern that described in Aspectj in Action be implemented using Spring AOP ?


  • #2
    Can you describe it. I do have that book, but it's in my office and I'm at home. And anyway, for the sake of other readers, it would be good to have all the information here.


    • #3
      Hi Rod,

      l think l can't describe better than Mr. Ramnivas Laddad ,
      Here is the link to the topic ,



      • #4
        The usual technique with Spring AOP would be to use a MethodInterceptor to manage a threadlocal binding. This still normally means that the code down the stack would need to know how to get that threadlocal. However, you could always have additional advices on methods further down the call stack that added behaviour that was aware of the threadlocals, so that the eventual target wasn't. That way would be more like the AspectJ way.

        But overall, AspectJ is more elegant for doing this kind of thing, if you want to avoid any change to the methods down the stack.


        • #5
          Actually l don't know what's the mechanism did the wormhole job ,
          but from the description of the book , it seem no threadlocals involved ...seen muck like a time machine for me ...hihi

          Here is quote from the book , pg 256,257.

          The wormhole pattern makes context information from a caller available to a
          callee—without having to pass the information as a set of parameters to each
          method in the control flow. For example, consider an authorization system,
          where many methods need to know who invoked them in order to determine if
          the caller should be allowed to execute the operation. The wormhole allows the
          methods to access the caller object and its context to obtain this information.
          By creating a direct route between two levels in the call stack, you create a
          wormhole and avoid linearly traveling through each layer. This saves you from
          having to modify the call chain when you want to pass additional context information,
          and it prevents API pollution.
          If you don’t use AspectJ, there are two ways to pass the caller’s context in a multithreaded
          environment: you can pass additional parameters containing context
          or you can use thread-specific storage to set and access the context information.
          In either case, multiple modules are involved in the logic that is passing the context.
          The first way of passing a parameter causes API pollution—every method in
          the execution stack must have extra parameters to pass on the context collected.
          The second way requires the caller to create a ThreadLocal variable to store the
          context information and set its context. While the second approach avoids API
          pollution, it entails changes in both caller and callee implementation and
          requires an understanding of how the context is stored.
          l concern about this pattern , because l encountered two problems while coding , l don't know whether it is the right solution for me or not ....

          1. security problem - how to pass the authorized user object (with user info) into a "need intercept" method without API pollution.

          2. ugly arguments problem - can l pass something like numberPerPage, currentPage, sortColumn, sortDirection, filter1, filter2, filter3 into the DAO.findSomething(keyword) method without pollute it API -->

          DAO.findSomething(keyword,numberPerPage, currentPage, sortColumn, sortDirection, filter1, filter2, filter3 )
          l described the problem else where , but seen people not interested,

          1 and 2 are the same problem for me .

          l think acegi security using threadlocal (the well know location) solved the problem 1 ....



          • #6
            That was part of my point. With AspectJ you don't need a ThreadLocal. Although it's not necessarily a bad implementation strategy...