This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
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.
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 -->