Leon, > As far as I see I have two opportunuties: > 1. To alter all interfaces in all layers and add a CallContext > parameter which would contain additional information gathered in the > top level and evaluated on demand > or 2. Have this CallContext object in somewhere in the VM, where I can > access it from everywhere in the application without to actually > change interfaces. The only location for the second case is imho the > current Thread.
As much as I cringe bringing this up, there is another possibility: use a ThreadLocal. You can basically use the Thread as a storage device, which sort of fits into your solution #2. The advantage is that you do not have to subvert the existing thread management strategy in Tomcat. > Now I have the unpleasant > situation that i need some information pretty deep in some use cases > of the application (like current locale) which I only have at the top > (servlet) level. I think that if you really need this information deep in your code, then you simply should modify your interfaces, etc. I realize that you probably want to get this solved as quickly as possible, but if you start coming up with unusual ways of getting data from one part of the call chain to another, then people who have to work on your code are going to get confused and angry. If you decide to do something crazy, make sure you document it fully, including the reasons why you didn't use standard method parameters to achieve the same end. -chris
signature.asc
Description: OpenPGP digital signature