commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject RE: COMMONS UPLOAD QUESTION "request.getParameter()"
Date Wed, 07 Apr 2004 14:24:58 GMT


> -----Original Message-----
> From: Inger, Matthew [mailto:Inger@Synygy.com]
> Sent: Wednesday, April 07, 2004 5:41 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: COMMONS UPLOAD QUESTION "request.getParameter()"
>
>
> PS:  The wrapper approach DOES work because you would
> then just assume the convention that getParameter()
> would return an absolute path of where the file was
> stored on disk.  Yes this has to assume you're using a
> DiskFileItemFactory,  But if you want the simplicity
> for the caller, that's a reasonable limitation.

Yuk. This wouldn't even work for DiskFileItemFactory. Whether any given item
is on disk or in memory is based on its size and on a configured threshold
value. If I called getParameter("foo") and got back a String, how would I
know if it was a path to a file, or just the content of the part? Remember,
now that you've simplified this to using getParameter(), I won't have a
FileItem to ask what type of item it is any more - unless you go around the
getParameter() call, which was my point in the first place.

> Finally, I'm not assuming anything about STRUTS.
> Controller and Action are general terms having to deal
> with any decent MVC framework.  There's nothing that
> says you couldn't have just Servlet classes, and have
> a BaseServlet which you would always extend.  The bottom
> line is that whatever pattern you use for your servlet,
> you can do this.  All you would have to do would be to
> make sure to create the FileUpload, if necessary, and
> call the UploadManager.put method.
>
> The wrapper class without proxies is problematic due to
> API changes, and that you're only interested in a few
> different methods which you would need to override the
> behavior?  Why should your code have to adapt if some
> method irrelevant to what you're doing is changed or added?
>
> I've given two simplistic approaches.  Either could be
> implemented within a reasonably small amount of code
> (1 - 2 classes).  Why not provide them to the users, and
> let them use it if they want?

Feel free to make something available somewhere for folks to use. However,
these solutions do not appear to be either simplistic or particularly
workable to me, and I'm not interested in adding them to FileUpload.

--
Martin Cooper


>
>
> -----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
>
>



---------------------------------------------------------------------
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