Thanks for your response Craig,
actually I have read about performance problems of ThreadLocals. I have tested with JDK 1.2.2, and the patch works, but I do not want to slow down the app for this issue, so still looking for a better solution.
Anyway, I wonder why by inspecting a thread, we can not know which one request belongs to, or in other words take the request (or session) instance from the thread instance. It seems for me a little stupid to pass the HttpServletRequest in both directions:
* BaseAction -> ExtendedAction: in doPerform() called from perform(), and
* ExtendedAction -> BaseAction: in my call to getData(...)
when already sevlet engine ¿should? know it, from the thread.
Is not there a table request/thread relationship somewhere which I could check from my base action?
Anyone else figures out a solution?
Otherwise I would go for passing getData(request), but is embarrassing since some apps already began should be modified.
Thanks in advance,
Adolfo.
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
To: Struts Users Mailing List <[EMAIL PROTECTED]>
Subject: Re: (Un)expected behaviour in Action instance variables?
Date: Tue, 21 Jan 2003 12:25:21 -0800 (PST)
On Tue, 21 Jan 2003, Adolfo Miguelez wrote:
> Date: Tue, 21 Jan 2003 10:26:49 +0000
> From: Adolfo Miguelez <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: (Un)expected behaviour in Action instance variables?
>
> Hi,
>
> fortunately, after more testing theory is right and it happends that should
> happen. You are right.
>
> It is my fault since I was testing the variable after previous asignment so
> the variable got the different values because I was asigning a new value in
> every execution, previously to the logging. The pointer is anyway unique,
> since the Action instance is the same.
>
> My next attemp will be to use ThreadLocal variables to try to made every
> value of the variable take different values for every execution (Thread).
> Not very polite perhaps, but I save to pass the request in every accesor
> invocation.
>
ThreadLocal is definitely not free from a performance perspective,
particularly on pre-1.4 JDKs. I think you're also looking at a path that
is going to dramatically increase the difficulty of maintaining this code
later.
Far better is to pass in the variables you need as parameters.
> Apologises and thanks,
>
> Adolfo
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
