Hey nikunj,

Why don't you implement SessionAware in your action and try?

This means if you need to access, for example, session data, you need to
implement SessionAware rather than calling ActionContext.getSession().

Regards,
ravindra

-----Original Message-----
From: nikunj [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 26, 2008 6:54 PM
To: 'Struts Users Mailing List'
Subject: RE: ExecuteAndWaitInterceptor Issue - ThreadLocal object

Nils,

Try to understand my problem.
I don't wana change my method signature.
I have no problem to make another overloaded method.
But I don't want to change my original method.
You replied me with changing my original method.

Boolean isValidUser(HttpServletRequest request)
{
// don't want to change content of function
}


 Boolean isValidUser(Map<String,Object> requestMap)
{
        ______________________________
        Need to change over here but what?
        Please describe clearly. Not like extractDataFromRequest function
}


Regards,
Nikunj


-----Original Message-----
From: Nils-Helge Garli Hegvik [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 26, 2008 2:26 PM
To: Struts Users Mailing List
Subject: Re: ExecuteAndWaitInterceptor Issue - ThreadLocal object

The other way around, something like this:

Boolean isValidUser(HttpServletRequest request) {
  Map data = extractDataFromRequest(request);
  isValidUser(data);
}

Boolean isValidUser(Map data) {
}

Note that you can't use the Struts 2 RequestMap either since it's
backed by the actual request object. So either you have to copy the
values in the map, or even better, extract the actual
objects/parameters the method need to do it's logic and pass them as
parameters instead.

Nils-H

On Wed, Nov 26, 2008 at 9:34 AM, nikunj <[EMAIL PROTECTED]> wrote:
> Ha ha
>
>
> You are right.
>
> But I'm having method like
>
> Boolean isValidUser(HttpServletRequest request)
> {
> }
>
>
> As u said, I am going to make another
>
> Boolean isValidUser(Map<String,Object> requestMap)
> {
>        ______________________________
> }
>
>
> Now tell me what I should write in above blank line to call my actual
> function.
>
>
> Regards,
> Nikunj
>
> -----Original Message-----
> From: Nils-Helge Garli Hegvik [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 26, 2008 1:32 PM
> To: Struts Users Mailing List
> Subject: Re: ExecuteAndWaitInterceptor Issue - ThreadLocal object
>
> I'm having a hard time understanding why refactoring your utility
> class would have a serious impact on the migration time. If it's just
> that you don't want to change the signature of your utility method
> because it's used many other places, then create a new utility method
> with the required parameters and extract the common bits. That way you
> have kept your old method, created a new one and shared the common
> code between them:
>
> Before:
>
> public static void doSomething(HttpServletRequest request) {
>   // Do something with the request
> }
>
> After:
>
> public static void doSomething(HttpServletRequest request) {
>   // Extract params from request
>   doSomething(param1, param2, param3);
> }
>
> public static void doSomething(Object param1, Object param2, Object
param3)
> {
>  // Do whatever you need with the params
> }
>
> Nils-H
>
> On Wed, Nov 26, 2008 at 7:57 AM, nikunj <[EMAIL PROTECTED]>
wrote:
>> Thanks Nils-H
>>
>> Actually I am migrating my existing application, need to reduce migration
>> time.
>>
>> Is there any way to make request object as common for all available
> thread,
>> So that we no need to extract the information of request object.
>>
>> Regards,
>> Nikunj
>>
>>
>> -----Original Message-----
>> From: Nils-Helge Garli Hegvik [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, November 26, 2008 12:16 PM
>> To: Struts Users Mailing List
>> Subject: Re: ExecuteAndWaitInterceptor Issue - ThreadLocal object
>>
>> As you say, the request object can be recycled by the container after
>> the thread has executed [1]. You can't "fix" this as it's up to the
>> container to handle this. You have to refactor your code so it's not
>> passing the request object around to different threads. Typically you
>> would extract the information you need from the request and pass the
>> data you nedd to the new thread instead.
>>
>> Nils-H
>>
>> [1] - Servlet 2.4 specification, section SRV.4.10
>>
>> On Wed, Nov 26, 2008 at 6:29 AM, nikunj <[EMAIL PROTECTED]>
> wrote:
>>> Dear All,
>>>
>>>
>>>
>>> Servlet container is written to be single-threaded.
>>>
>>>
>>>
>>> That means that the "request" object isn't designed to be used after the
>>>
>>> thread that handled the request has finished executing. What is
>>>
>>> happening is this:
>>>
>>>
>>>
>>> 1) Thread1 handles request
>>>
>>> 2) Thread1 gives request to Tomcat
>>>
>>> 3) Tomcat starts Thread2 and executes your action
>>>
>>> 4) Thread1 finishes and cleans up request
>>>
>>> 5) Your action (on Thread2) tries to use the request
>>>
>>>
>>>
>>> Step #5 causes an exception in the container. Null pointer exeception
>>>
>>>
>>>
>>> How to fix this issue?
>>>
>>>
>>>
>>> Can any body help me?
>>>
>>>
>>>
>>> Thanks in advance
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Nikunj Mulani
>>>
>>> Applied Software Pvt. Ltd.
>>>
>>> Ahmedabad
>>>
>>> 91-98249 88262
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> __________ NOD32 3641 (20081126) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> __________ NOD32 3641 (20081126) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


__________ NOD32 3641 (20081126) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to