Thanks Matthew,

I suposse that servlet container, set null all objects when a request is
finished, no mather if thread is run and reference a rundata object, make a
sense.


-----Mensaje original-----
De: Matthew Inger [mailto:[EMAIL PROTECTED]]
Enviado el: viernes 31 de agosto de 2001 17:43
Para: [EMAIL PROTECTED]
Asunto: Re: Thread + RunData


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: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
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 ([EMAIL PROTECTED])
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: [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