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]
