commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: [PortletFileUpload] class compiling error
Date Sat, 02 Apr 2005 21:08:49 GMT
On Apr 2, 2005 1:17 AM, Pete Raleigh <pete.raleigh@lwwcm.com> wrote:
> That would be brilliant! At the moment it adds about 600KB to the WAR file,
> which isn't so bad... But I'm one of these people that get annoyed with
> companies like Microsoft when they release updates to products that are
> several megs in size. It's ok for broadband users, but what a waste in
> general.
> 
> I think I'm a little confused with the process I'm supposed to use. At the
> moment I perform the following steps (this is all for a JSR 168 Portlet):
> 1. Get the Action (encoded in the SubmitURI) - "viewSubmit" or "editSubmit"
> 2. Set up the multipart form processing values
> 3. If it is multipart then I process this and create a new List of the
> "keys"
> 4. When I need parameters I pass the "key" and look up the second List for
> the index and extract the values from the FileItem List. If the request
> wasn't a multipart request, then I simply extract the values from the
> Request object using the getParameter() method.
> 
> Should I be using the parseHeaders() at any stage?

No.

> Step 4 is where I've confused myself. Should I be creating a separate List
> for the keys and using an indexOf("key") to return the FileItem object from
> the first List, or is it just as quick to iterate the FileItem List without
> the need for extracting the keys in the first place (during Step 3)? Anyone
> done any tests on indexOf and Iterator(s)?

Once you have the list of items, it's really up to you how you use it.
If you want to use it in essentially the same way as you accessed
parameters before, you could simply iterate over the list and create a
map that goes from item name to item value.

> Just out of curiosity, does anyone also have a reference for what a standard
> POST and a multipart request headers look like? Otherwise, I can download
> Proxomitron (if it is still about) to view the headers.

There's a link to the RFC for multipart requests right at the top of
the front page of the Commons FileUpload web site. Non-multipart
requests are defined in the HTTP spec, which is RFC 2068.

--
Martin Cooper


> Cheers, Pete.
> 
> Freelance IBM LWWCM Consultant
> e: Pete.Raleigh@lwwcm.com
> w: http://www.lwwcm.com
> w: http://www.lclimited.co.uk
> m: +44 (0)77 9694 2827
> aim id: wartookman
> 
> 
> -----Original Message-----
> From: Martin Cooper [mailto:mfncooper@gmail.com]
> Sent: 02 April 2005 06:47
> To: Jakarta Commons Users List
> Subject: Re: [PortletFileUpload] class compiling error
> 
> On Apr 1, 2005 5:13 AM, Pete Raleigh <pete.raleigh@lwwcm.com> wrote:
> > Alfredo,
> >
> > After downloading all of the dependencies, I have managed to get the
> > Portlet to compile. A big "thank you" for your assistance. In WPS 5.1
> > there isn't a servlet-api.jar as such, it is located in the
> > AppServer/lib/j2ee.jar (for any users who can't seem to find it).
> >
> > After running a simple test, it also appears to be doing what it is
> > supposed to do. Do you know why there are so many dependencies as it
> > is a shame to have to package all of these JAR files within a WAR /
> > EAR for such a small piece of code?
> 
> What you ran into is an unfortunate side-effect of the current attempt at
> backwards compatibility with the FileUpload 1.0 release.
> PortletFileUpload extends FileUpload, FileUpload extends FileUploadBase, and
> FileUploadBase was heavily tied to the Servlet API in the 1.0 release. I
> have eliminated almost all of the Servlet dependencies in that class, but
> there are a couple that cannot be moved yet, because they are needed for
> backwards compatibility. These methods will be deprecated in the 1.1
> release, and then removed in the
> 1.2 release, so eventually that problem will go away.
> 
> To be honest, I hadn't noticed this particular issue up to now, but now that
> you've brought it to my attention, I'll look into how we can avoid it in the
> 1.1 release, since it's clearly a pain to have to compile a Portlet app
> against the Servlet API!
> 
> Once this is fixed, you will need only the Portlet (or Servlet) API and the
> Commons IO jars in addition to FileUpload itself.
> 
> --
> Martin Cooper
> 
> > Cheers, Pete.
> >
> > -----Original Message-----
> > From: Alfredo Ledezma Melendez
> > [mailto:alfredo.ledezma@mail.telcel.com]
> > Sent: 31 March 2005 22:51
> > To: Jakarta Commons Users List
> > Subject: RE: [PortletFileUpload] class compiling error
> >
> > Please check
> > http://jakarta.apache.org/commons/fileupload/dependencies.html
> >
> > Regards,
> > ____________________________________________
> > Alfredo Ledezma Melendez.
> > Costumer Record Management
> > Consultor Externo de Sistemas de Atencion a Clientes RadioMovil DIPSA, S.
> A.
> > de C. V.
> > Ejercito Nacional No. 488, Col. Anahuac, C.P. 11570 Mexico D.F.
> >
> > -----Original Message-----
> > From: Pete Raleigh [mailto:pete.raleigh@lwwcm.com]
> > Sent: Thursday, March 31, 2005 3:36 PM
> > To: commons-user@jakarta.apache.org
> > Subject: RE: [PortletFileUpload] class compiling error
> >
> > That's because it isn't a "servlet" - it's a portlet. Are these files
> > really necessary? It uses the ActionRequest object, rather than an
> > HttpServletRequest object - which are very different in a Portal
> > Server. I have been struggling with this all day and have still not
> > progressed very far. Has anyone managed to upload a file through a
> > Portlet (JSR 168) or is this not possible?
> >
> > Cheers, Pete.
> >
> > -----Original Message-----
> > From: Alfredo Ledezma Melendez
> > [mailto:alfredo.ledezma@mail.telcel.com]
> > Sent: 31 March 2005 22:29
> > To: pete.raleigh@lwwcm.com
> > Subject: RE: [PortletFileUpload] class compiling error
> >
> > I think the problem is the classpath value. Check that you have
> > tools.jar and servlet.jar in it.
> >
> > Regards,
> > ____________________________________________
> > Alfredo Ledezma Melendez.
> > Costumer Record Management
> > Consultor Externo de Sistemas de Atencion a Clientes RadioMovil DIPSA, S.
> A.
> > de C. V.
> > Ejercito Nacional No. 488, Col. Anahuac, C.P. 11570 Mexico D.F.
> >
> > -----Original Message-----
> > From: Pete Raleigh [mailto:pete.raleigh@lwwcm.com]
> > Sent: Thursday, March 31, 2005 2:09 PM
> > To: commons-user@jakarta.apache.org
> > Subject: [PortletFileUpload] class compiling error
> >
> > I would appreciate some assistance in creating a JSR 168 compliant
> > File Upload Portlet. I have downloaded the 1.1-dev JAR from the
> > commons website (Nightly build) but seem to be having problems compiling.
> >
> > My (trimmed) code is as follows:
> > ...
> > import org.apache.commons.fileupload.FileItem;
> > import org.apache.commons.fileupload.FileUploadException;
> > import org.apache.commons.fileupload.disk.DiskFileItemFactory;
> > import org.apache.commons.fileupload.portlet.PortletFileUpload;
> > ...
> > private String processUpload(ActionRequest request, ActionResponse
> > response) {
> >         String txt = "";
> >
> >         File tmpDir = new File("D:\\Temp\\Upload");
> >         DiskFileItemFactory dfif = new DiskFileItemFactory(10240, tmpDir);
> >         ...
> >         PortletFileUpload pfu = new PortletFileUpload(dfif);
> >         ...
> >         try
> >         {
> >                 List fileItems = pfu.parseRequest(request);
> >                 Iterator iter = fileItems.iterator();
> >
> >                 while (iter.hasNext())
> >                 {
> >                         FileItem item = (FileItem)iter.next();
> >                         if (item.isFormField())
> >                         {
> >                                 // Input text field
> >                                 txt += "FIELD NAME: " +
> > item.getFieldName + "<br>";
> >                                 txt += "VALUE: " + item.getString() +
> > "<br><br>";
> >                         } else {
> >                                 // Uploaded file
> >                                 txt += "FIELD NAME: " +
> > item.getFieldName()
> > + "<br>";
> >                                 txt += "FILE SIZE: " + item.getSize()
> > + "<br><br>";
> >                         }
> >                 }
> >
> >         } catch (FileUploadException fue) {
> >                 txt += "File Upload Exception: " + fue + "<br>";
> >         } catch (Exception e) {
> >                 txt += "Exception: " + e + "<br>";
> >         }
> >         ...
> > }
> > ...
> >
> > The error message I receive is:
> > com\lcltd\raleigh\jsr168\WCMTools.java:139: cannot access
> > javax.servlet.http.HttpServletRequest
> > file javax\servlet\http\HttpServletRequest.class not found
> >                                 List fileItems =
> pfu.parseRequest(request);
> >                                                     ^
> > 1 error
> >
> > I have struggled to find what I am doing wrong and have seen plenty of
> > references to the HttpServletRequest version (1.0) on Google, but
> > nothing for a Portlet code example version. What have I missed? :) Do
> > I need to write additional code for one of these classes - is this
> > class and other classes in the package unfinished? Does anyone have
> > any example (working) snippets?
> >
> > Any help you could provide would be greatly appreciated.
> >
> > Cheers, Pete.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

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


Mime
View raw message