commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Inger, Matthew" <In...@Synygy.com>
Subject RE: COMMONS UPLOAD QUESTION "request.getParameter()"
Date Wed, 07 Apr 2004 12:32:21 GMT
Thread takes care of the cleanup for you.  If you look at the
JDK source code (and the documentation states this as well),
each Thread has a member variable:

	Map threadLocals

And the ThreadLocal class simply accesses that map directly
(as it's in the same package):

   public Object get() {
	Thread ourThread = Thread.currentThread();
        Map map = ourThread.threadLocals;
	Object value = map.get(key);
        if (value==null && !map.containsKey(key)) {
            if (map == Collections.EMPTY_MAP)
                map = ourThread.threadLocals = new
HashMap(INITIAL_CAPACITY);
            value = initialValue();
            map.put(key, value);
        }
	return value;
    }

Thus, when the thread completes, and is eligible for garbage collection,
all of the instances created by ThreadLocal objects associated with that
thread are available for garbage collection.  Therefore, no cleanup is
required.


-----Original Message-----
From: Martin Cooper [mailto:martinc@apache.org]
Sent: Tuesday, April 06, 2004 5:32 PM
To: commons-dev@jakarta.apache.org
Subject: Re: COMMONS UPLOAD QUESTION "request.getParameter()"



"Inger, Matthew" <Inger@Synygy.com> wrote in message
news:F369B5B779D1794FB19653920D62D3BD045772@kossuth.synygy.net...
> One idea:
>
> First, create a container to hold the upload instances, using a
ThreadLocal
> variable to key the instances by thread, and ensure that they don't
survive
> beyond the thread's lifespan.  ThreadLocal is also synchronized, so all
the
> main concerns have been take care of.

Whoa! First proxies and now thread local - this just seems much more
complicated than it needs to be. As I mentioned before, I'm much more
inclined to use an HttpServletRequestWrapper approach, and make that an
optional add-on for Servlet 2.3 environments.

Note that, with a thread local approach, you would need a way to clean up
the thread local data after each request, not just when the thread goes
away. Otherwise you'd still have it hanging around when another request
comes in and is handled on the same thread. That's going to be error-prone.

>
> final class UploadManager {
>    private static ThreadLocal uploads;
>
>    static {
>        uploads = new ThreadLocal();
>    }
>
>
>    public static final void put(FileUpload upload) {
>        uploads.set(upload);
>    }
>
>    public static final FileUpload get() {
>        return (FileUpload)uploads.get();
>    }
> }
>
>
> Then, in your controller, create the FileUpload, and put
> it into the UploadManager:
>
>    if (isFileUpload) {
>         FileUpload upload = ...;
>         UploadManager.put(upload);
>    }
>
> Finally, in your action handler:
>
>    FileUpload upload = UploadManager.get();
>    if (upload != null) {
>       ...
>    }
>
>
> Personally, i prefer the wrapper approach as it's neater.  Not to
> mention, everywhere you expect and upload, you're going to have to
> have an "if" statement to pull your parameters.  In best case, you'll
> have a utility method to do it for you based on whether the upload item
> for the current thread is present or not.

The wrapper approach doesn't entirely work for uploaded file items, at least
not without casting. You still need something more for file items, because
getParameter() returns a String, and, well, file items aren't strings. ;-)

By the way, are you assuming a particular usage scenario? The above code
looks like you're assuming Struts, because you mention a controller and
action handlers. We have no particular usage model for FileUpload beyond a
servlet.

--
Martin Cooper


>
>
>
> -----Original Message-----
> From: Martin Cooper [mailto:martinc@apache.org]
> Sent: Tuesday, April 06, 2004 1:41 AM
> To: Jakarta Commons Developers List
> Subject: RE: COMMONS UPLOAD QUESTION "request.getParameter()"
>
>
>
>
> > -----Original Message-----
> > From: Inger, Matthew [mailto:Inger@Synygy.com]
> > Sent: Monday, April 05, 2004 9:40 AM
> > To: 'Jakarta Commons Developers List'
> > Subject: RE: COMMONS UPLOAD QUESTION "request.getParameter()"
> >
> >
> > Aha... That my friend is where proxy classes come in.
> > If you make an InvocationHandler implementation which would
> > take in the original request and the a DefaultFileItemFactory.
> > You could intercept requests to getParameter, getParameterNames,
> > getParameterValues, and getParameterMap.  Those would call methods
> > internal to your invocation handler.  Everything else would delegate
> > to the original request.  This would shield you from Servlet API
> > dependencies, since the java.lang.Proxy.newInstance method would build
> > your proxy instance based on whatever the runtime definition of the
> > HttpServletRequest class is.
> >
> > If you're not familiar with proxy classes, please read up on
> > java.lang.Proxy, and java.lang.InvocationHandler.  Notice that
> > there is no depencency on what version of the servlet API is being
> > used.  I've used this strategy before to shield from JDBC
> > implementation
>
> I'm familiar with proxies, thanks. However, I'd much rather make this type
> of wrap available as an optional Servlets 2.3 add-on than bring proxies
into
> the picture.
>
> I'm also not completely convinced that using proxies would actually work,
> since it's not legal to wrap a request object in Servlets 2.2, and some
> containers hold to this very rigidly. (Yes, I know it's not the same as a
> regular wrapper, but some containers really are extremely picky.)
>
> BTW, any thoughts on how best to make the FileItem instances, for uploaded
> files, available to the client, once the request object is
indistinguishable
> from a regular request that doesn't have such things?
>
> --
> Martin Cooper
>
>
> > I can supply the full implementation if you'd like.  Barring any
dissent,
> > i can post a patch to the tracker.
> >
> >
> > final class RequestWrapperInvocationHandler
> >         implements InvocationHandler
> > {
> >     private HttpServletRequest req;
> >
> >     public RequestWrapperInvocationHandler(HttpServletRequest req,
> >                                            DefaultFileItemFactory
factory)
> >         throws FileUploadException {
> >         super();
> >         this.req = req;
> >         this.factory = factory;
> >
> >         initParameters();
> >     }
> >
> >     [implementation details left out here]
> >
> >     public Object invoke(Object proxy, Method method, Object[] args)
> >             throws Throwable
> >     {
> >         if (method.getName().equals("getParameter"))
> >             return getParameter((String)args[0]);
> >         else if (method.getName().equals("getParameterValues"))
> >             return getParameterValues((String)args[0]);
> >         else if (method.getName().equals("getParameterNames"))
> >             return getParameterNames();
> >         else if (method.getName().equals("getParameterMap"))
> >             return getParameterMap();
> >         else
> >             return method.invoke(req, args);
> >     }
> > }
> >
> > public final class RequestWrapper {
> >     private RequestWrapper () {
> >
> >     }
> >
> >     public static final HttpServletRequest wrap(HttpServletRequest req,
> >                                                 DefaultFileItemFactory
> > factory)
> >         throws Exception {
> >         InvocationHandler handler = new
> > RequestWrapperInvocationHandler(req,
> >
> > factory);
> >         return (HttpServletRequest)Proxy.newProxyInstance(
> >                 Thread.currentThread().getContextClassLoader(),
> >                 new Class[] { HttpServletRequest.class },
> >                 handler);
> >     }
> > }
> >
> >
> > > -----Original Message-----
> > > From: Inger, Matthew [mailto:Inger@Synygy.com]
> > > Sent: Friday, April 02, 2004 2:19 PM
> > > To: 'Jakarta Commons Developers List'
> > > Subject: RE: COMMONS UPLOAD QUESTION "request.getParameter()"
> > >
> > >
> > > [snip] I would personally like to see an HttpServletRequest
> > implementation
> > > provided which would take the original request, pass it to a
FileUpload
> > > instance for parsing, and process the returned FileItem
> > instances so that
> > > things like "getParameter()" and so forth would work properly.
> >
> > That would look a lot like this, I assume:
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20523
> >
> > The only problem with that is that it would introduce a Servlet 2.3
> > dependency, while FileUpload currently works in Servlet 2.2
applications.
> > Still, it's definitely a good idea, and could be part of a FileUpload
2.x
> > release, or potentially an optional add-on to a 1.x release.
> >
> > --
> > Martin Cooper
> >
> >
> > > (hmm.... maybe i should just write that class).
> > >
> > > -----Original Message-----
> > > From: Artstar910@aol.com [mailto:Artstar910@aol.com]
> > > Sent: Friday, April 02, 2004 4:20 PM
> > > To: commons-dev@jakarta.apache.org
> > > Subject: COMMONS UPLOAD QUESTION "request.getParameter()"
> > >
> > >
> > > I have been searching the Internet for a practical Java-based
uploading
> > > solution that is standardized. I have found that there are many
> > Java apps
> > > and tools
> > > that people have built for this purpose but I find that each have
their
> > > short
> > > falls and must be customized to perform my tasks. My tasks are not
> > > complicated at all, but apparently there is no information on how
> > > to perform
> > > these task
> > > in the JavaDocs or even newsgroups. Here is what I am looking to do:
> > >
> > > I need to input the fields from this for into my database which
> > > is perfectly
> > >
> > > normalized.
> > >
>
> --------------------------------------------------------------------------
> > > upload.jsp
> > >
>
> --------------------------------------------------------------------------
> > > <HTML>
> > > <HEAD>
> > > <META http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
> > > </HEAD>
> > > <BODY style="font-family: Arial, Helvetica, sans-serif;">
> > >     <FORM method="POST" action="add_output.jsp"
> > > encrypt="multipart/form-data"
> > > >
> > > <TABLE align="left">
> > >         <TR>
> > >             <TD>
> > >             AUTHOR <INPUT type="text" name="author" size="20"
> > > maxlength="50"
> > >
> > > value=""></TD>
> > >         </TR>
> > >         <TR">
> > >             <TD>
> > >             ARTICLE SHORT DESCRIPTION <INPUT type="text"
> > > name="shortDescription" size="30" maxlength="100" value=""></TD>
> > >         </TR>
> > >         <TR>
> > >             <TD>
> > >         ARTICLE LONG DESCRIPTION <INPUT type="text"
> > > name="longDescription"
> > > size="30" maxlength="120" value=""> *MAY BE NULL</TD>
> > >         </TR>
> > >         <TR>
> > >             <TD>
> > >             ARTICLE CONTENT <TEXTAREA name="articleContent" rows="20"
> > > cols="80"></TEXTAREA></TD>
> > >         </TR>
> > >         <TR>
> > >             <TD>
> > >             <INPUT type="FILE" name="FILE1" size="50"></TD>
> > >         </TR>
> > >         <TR>
> > >             <TD>
> > >             <INPUT type="submit" value="Insert" onClick=""><INPUT
> > > type="Reset"></TD>
> > >         </TR>
> > >     </TABLE>
> > >     </FORM>
> > > </BODY>
> > > </HTML>
> > >
>
> --------------------------------------------------------------------------
> > > Here is the catch. I want to input the text fields directly in to
their
> > > appropriate fields in the database but I want the file field to grab
the
> > > file name
> > > and input that in the newly inputted row. I also need the file
> > to uploaded
> > > to
> > > a file folder on my server. I know to pull the file name to input
> > > it in the
> > > database I need to use the getName() method. My problem is in the
> > > fact that
> > > I do
> > > not know which method I need to use to parse the other fields in
> > > my form. On
> > >
> > > my other forms for inputting info into my database I use JSP and
> > > I use the
> > > request.getParameter. As you know this does not work with the
multipart
> > > encryption. In the JavaDocs it does not directly say which method
> > > should be
> > > called to
> > > parse this information. I chose commons specifically because it had a
> > > multipart
> > > parser in it. I also like the fact that it is somewhat
> > > standardized. I need
> > > to make sure that I do this right because I find that some many
> > people on
> > > the
> > > Internet write bad code and I would perfer not to fall into that.
> > > I like to
> > > build most of my stuff in JSP and it is easy to change into
> > servlets if I
> > > need
> > > to. I have tried a few other methods but I find them very
> > sloppy. I tried
> > > the
> > > 3-Step approach. Where you have a data input JSP which then goes
> > > to another
> > > JSP
> > > which parses the form and inputs the data into the database
> > then calls the
> > > row
> > > that the data is in and places that info into a hidden field.
> > > Then that page
> > >
> > > displays the file input box for the user to select the file. Then
> > > once that
> > > form is submitted to the next JSP document it, in theory, is supposed
to
> > > find
> > > the field in the database to insert the file name in the
> > appropriate field
> > > and
> > > upload the document to a file on the server. I would appreciate
> > it if you
> > > can
> > > steer me in the right direction or send me a snippet, or link
> > to somewhere
> > > that
> > > documents this.
> > >
> > > Thank you very much,
> > > Matt Newman
> > > Student @ LACC
> > >
> > > artstar910@aol.com
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org




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

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


Mime
View raw message