You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by "Gregorio, Nelson" <Ne...@sonda.com> on 2001/08/31 17:44:58 UTC

Thread + RunData

I´m triying creat a class extending Thread and passed rundata as atribute in
constructor class, but the objects referenced by rundata (getUser(),
getParameters(), getTemplateInfo(), etc) are in null, there are any way to
access them in a class extended a Thread class.

thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: Thread + RunData

Posted by Matthew Inger <ma...@sedonacorp.com>.
ps:  once you create this object, you can create a new RunData object to 
pass along
with the following statements:

        MapRequestWrapper wrapper = new 
MapRequestWrapper(data.getRequest());
        RunData data2 = RunDataFactory.getRunData(wrapper, 
data.getResponse(), data.getServletConfig());

    then pass data2 to your thread.


Matthew Inger wrote:

> Gregorio, Nelson wrote:
>
>> I´m triying creat a class extending Thread and passed rundata as 
>> atribute in
>> constructor class, but the objects referenced by rundata (getUser(),
>> getParameters(), getTemplateInfo(), etc) are in null, there are any 
>> way to
>> access them in a class extended a Thread class.
>>
>> thanks.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>>
>>
> This is a function of the servlet engine if i'm reading your problem 
> right.  I'll use tomcat for
> my example (and I encountered this very same problem).  Tomcat uses a 
> pool of HttpServletRequest
> and HttpServletResponse objects to service incoming requests.  When a 
> request is finished
> being serviced, the contents of the request and response are 
> considered to be volatile.
> That is, their data is undefined (and in fact, tomcat will essentially 
> null everything out).
> So if you're kicking off a background thread, and sending back some 
> sort of response,
> the second the response's output buffer is flushed by the servlet 
> container, you're possibly
> going to lose any data in your request.
>
> Solution:
>    Create a class which takes in an HttpServletRequest, and in the 
> constructor copies all the
>    data.  Then pass that class around as the object in the request. 
> Example:
>
>    public class MapRequestWrapper implements HttpServletRequest
>    {
>        private Map parameters;
>        public MapRequestWrapper(HttpServletRequest req)
>        {
>            parameters = new HashMap();
>            Enumeration e = req.ParameterNames();
>            while (e.hasMoreElements())
>            {
>                String name = (String)(e.nextElement());
>                parameters.put(name, req.getParameterValues());
>            }
>
>            // Copy other data here....
>        }
>
>        public String getParameter(String name)
>        {
>                String[] vals = (String[])(parameters.get(name));
>                if (vals != null && vals.length > 0)
>                    return vals[0];
>                else
>                    return null;
>        }
>
>        // Implement the rest of the HttpServletRequest interface to 
> return
>        // data that you have copied from the original request.
>
>     }
>        
> As far as how to tell the RunData to use a different HttpServletRequest
> object.  You can't directly, but you can probably cast RunData to
> TurbineRunData, and use the setRequest method on that class......
>
> I have done this successfully (though not with turbine).  The project 
> I did
> this on, uses webmacro, and I used the WebContext.reinitialize to reset
> the request object.
>
> As a matter of fact, this kind of delegation pattern is useful for a 
> lot of
> other things.  Especially in dealing with file uploads.  I use the 
> o'reilly
> servlet class MultipartRequest.  But I avoid the programmer ever seeing
> it, by wrapping that and the original request object in another object 
> which
> implements HttpServletRequest, and gets parameters from the appropriate
> place.  So for file uploads, the caller simply gets the parameter 
> value, and
> that returns them the absolute path where the file was stored during the
> upload.
>
>        



-- 
Matt Inger (matt.inger@sedonacorp.com)
Sedona Corporation
455 S. Gulph Road, Suite 300
King of Prussia, PA 19406
(484) 679-2213
"Self-respect - the secure feeling that no one,
 as yet, is suspicious." -H.L. Mencken 




---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: Thread + RunData

Posted by Matthew Inger <ma...@sedonacorp.com>.
PS:  If you use RunDataFactory.getRunData(...), don't forget to put it 
back in the pool
after the thread is finished by calling the 
RunDataFactory.putRunData(data) method.


Matthew Inger wrote:

> Gregorio, Nelson wrote:
>
>> I´m triying creat a class extending Thread and passed rundata as 
>> atribute in
>> constructor class, but the objects referenced by rundata (getUser(),
>> getParameters(), getTemplateInfo(), etc) are in null, there are any 
>> way to
>> access them in a class extended a Thread class.
>>
>> thanks.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>>
>>
> This is a function of the servlet engine if i'm reading your problem 
> right.  I'll use tomcat for
> my example (and I encountered this very same problem).  Tomcat uses a 
> pool of HttpServletRequest
> and HttpServletResponse objects to service incoming requests.  When a 
> request is finished
> being serviced, the contents of the request and response are 
> considered to be volatile.
> That is, their data is undefined (and in fact, tomcat will essentially 
> null everything out).
> So if you're kicking off a background thread, and sending back some 
> sort of response,
> the second the response's output buffer is flushed by the servlet 
> container, you're possibly
> going to lose any data in your request.
>
> Solution:
>    Create a class which takes in an HttpServletRequest, and in the 
> constructor copies all the
>    data.  Then pass that class around as the object in the request. 
> Example:
>
>    public class MapRequestWrapper implements HttpServletRequest
>    {
>        private Map parameters;
>        public MapRequestWrapper(HttpServletRequest req)
>        {
>            parameters = new HashMap();
>            Enumeration e = req.ParameterNames();
>            while (e.hasMoreElements())
>            {
>                String name = (String)(e.nextElement());
>                parameters.put(name, req.getParameterValues());
>            }
>
>            // Copy other data here....
>        }
>
>        public String getParameter(String name)
>        {
>                String[] vals = (String[])(parameters.get(name));
>                if (vals != null && vals.length > 0)
>                    return vals[0];
>                else
>                    return null;
>        }
>
>        // Implement the rest of the HttpServletRequest interface to 
> return
>        // data that you have copied from the original request.
>
>     }
>        
> As far as how to tell the RunData to use a different HttpServletRequest
> object.  You can't directly, but you can probably cast RunData to
> TurbineRunData, and use the setRequest method on that class......
>
> I have done this successfully (though not with turbine).  The project 
> I did
> this on, uses webmacro, and I used the WebContext.reinitialize to reset
> the request object.
>
> As a matter of fact, this kind of delegation pattern is useful for a 
> lot of
> other things.  Especially in dealing with file uploads.  I use the 
> o'reilly
> servlet class MultipartRequest.  But I avoid the programmer ever seeing
> it, by wrapping that and the original request object in another object 
> which
> implements HttpServletRequest, and gets parameters from the appropriate
> place.  So for file uploads, the caller simply gets the parameter 
> value, and
> that returns them the absolute path where the file was stored during the
> upload.
>
>        



-- 
Matt Inger (matt.inger@sedonacorp.com)
Sedona Corporation
455 S. Gulph Road, Suite 300
King of Prussia, PA 19406
(484) 679-2213
"Self-respect - the secure feeling that no one,
 as yet, is suspicious." -H.L. Mencken 




---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org


Re: Thread + RunData

Posted by Matthew Inger <ma...@sedonacorp.com>.
Gregorio, Nelson wrote:

>I´m triying creat a class extending Thread and passed rundata as atribute in
>constructor class, but the objects referenced by rundata (getUser(),
>getParameters(), getTemplateInfo(), etc) are in null, there are any way to
>access them in a class extended a Thread class.
>
>thanks.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
This is a function of the servlet engine if i'm reading your problem 
right.  I'll use tomcat for
my example (and I encountered this very same problem).  Tomcat uses a 
pool of HttpServletRequest
and HttpServletResponse objects to service incoming requests.  When a 
request is finished
being serviced, the contents of the request and response are considered 
to be volatile.
That is, their data is undefined (and in fact, tomcat will essentially 
null everything out).
So if you're kicking off a background thread, and sending back some sort 
of response,
the second the response's output buffer is flushed by the servlet 
container, you're possibly
going to lose any data in your request.

Solution:
    Create a class which takes in an HttpServletRequest, and in the 
constructor copies all the
    data.  Then pass that class around as the object in the request. 
 Example:

    public class MapRequestWrapper implements HttpServletRequest
    {
        private Map parameters;
        public MapRequestWrapper(HttpServletRequest req)
        {
            parameters = new HashMap();
            Enumeration e = req.ParameterNames();
            while (e.hasMoreElements())
            {
                String name = (String)(e.nextElement());
                parameters.put(name, req.getParameterValues());
            }

            // Copy other data here....
        }

        public String getParameter(String name)
        {
                String[] vals = (String[])(parameters.get(name));
                if (vals != null && vals.length > 0)
                    return vals[0];
                else
                    return null;
        }

        // Implement the rest of the HttpServletRequest interface to return
        // data that you have copied from the original request.

     }
         

As far as how to tell the RunData to use a different HttpServletRequest
object.  You can't directly, but you can probably cast RunData to
TurbineRunData, and use the setRequest method on that class......

I have done this successfully (though not with turbine).  The project I did
this on, uses webmacro, and I used the WebContext.reinitialize to reset
the request object.

As a matter of fact, this kind of delegation pattern is useful for a lot of
other things.  Especially in dealing with file uploads.  I use the o'reilly
servlet class MultipartRequest.  But I avoid the programmer ever seeing
it, by wrapping that and the original request object in another object which
implements HttpServletRequest, and gets parameters from the appropriate
place.  So for file uploads, the caller simply gets the parameter value, and
that returns them the absolute path where the file was stored during the
upload.

         

-- 
Matt Inger (matt.inger@sedonacorp.com)
Sedona Corporation
455 S. Gulph Road, Suite 300
King of Prussia, PA 19406
(484) 679-2213
"Self-respect - the secure feeling that no one,
 as yet, is suspicious." -H.L. Mencken 




---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org