tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leon Rosenberg" <>
Subject Re: Is there an easy way to replace http-processor threads?
Date Fri, 21 Jul 2006 13:46:23 GMT
Thank you Christopher, but Peter made the same (ThreadLocal) proporsal
a bit earlier in the thread.
However, as for the other point concerning interface change, I'm not
looking for a quick solution but rather redesign our current
architecture. The 'hidden' parameter transfer may be not a best
practice, but it has some great advantages. For example, if I need the
current user's country somewhere deep in the BL I could change all
interfaces inbetween and add the country (or locale) parameter, but
than I have one of nine methods having this parameter. If I am
consequent, I'd have to add standard parameters like current userId,
locale, etc to each method in each interface which wouldn't make
method signatures better readable. Consider:
public void sendMessage(Message message) against
public void sendMessage(Message message, UserId currentUserId,
SessionId currentSessionId, Locale currentLocale.....)
which one is better to understand?

Using a hidden CallContext is like using the request/session in the
webapp or using interceptors/piggybaging in middleware. Since we are
talking about must-have (but not must use) parameters in each call, I
think the advantages are greater than the drawbacks.


On 7/21/06, Christopher Schultz <> wrote:
> 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

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message