Is there an easy way to replace http-processor threads?

[Leon Rosenberg <ro...@googlemail.com>]

Hi,

I have following situation. I have a pretty complex application with
many layers most of them fully independent from the http-specifica.
The layers are coupled via interfaces. 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.

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.

Therefore, is there a possibility to configure (without actual
patching) tomcat to use different HttpWorkerThreads/Factories?

regards
Leon

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Is there an easy way to replace http-processor threads?

[Christopher Schultz <ch...@christopherschultz.net>]

Leon,

> 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?

I agree. I wouldn't recommend adding every single required piece of data
to all of your method calls. Rather, consider creating a class that
contains all of this information. Say, UserData. Then, add a parameter
of that type to each of your methods, and propagate them through the
rest of your interfaces.

If you find that, in the future, you need another piece of data, just
add it to the UserData object and none of your interfaces have to change.

-chris

Re: Is there an easy way to replace http-processor threads?

[Leon Rosenberg <ro...@googlemail.com>]

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.

regards
Leon




On 7/21/06, Christopher Schultz <ch...@christopherschultz.net> 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: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Is there an easy way to replace http-processor threads?

[Christopher Schultz <ch...@christopherschultz.net>]

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