View Full Version : Wormhole pattern in spring ?
Apr 21st, 2005, 11:50 AM
Can Wormhole Pattern that described in Aspectj in Action be implemented using Spring AOP ?
May 4th, 2005, 12:16 PM
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.
May 5th, 2005, 09:16 AM
l think l can't describe better than Mr. Ramnivas Laddad , :)
Here is the link to the topic ,
May 5th, 2005, 09:23 AM
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.
May 5th, 2005, 10:07 AM
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 ....:)
May 5th, 2005, 10:09 AM
That was part of my point. With AspectJ you don't need a ThreadLocal. Although it's not necessarily a bad implementation strategy...
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.