Return-Path: Delivered-To: apmail-incubator-jspwiki-user-archive@locus.apache.org Received: (qmail 88766 invoked from network); 10 Oct 2008 11:37:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Oct 2008 11:37:27 -0000 Received: (qmail 77248 invoked by uid 500); 10 Oct 2008 11:37:26 -0000 Delivered-To: apmail-incubator-jspwiki-user-archive@incubator.apache.org Received: (qmail 77238 invoked by uid 500); 10 Oct 2008 11:37:26 -0000 Mailing-List: contact jspwiki-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jspwiki-user@incubator.apache.org Delivered-To: mailing list jspwiki-user@incubator.apache.org Received: (qmail 77227 invoked by uid 99); 10 Oct 2008 11:37:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Oct 2008 04:37:26 -0700 X-ASF-Spam-Status: No, hits=2.1 required=10.0 tests=DNS_FROM_SECURITYSAGE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of harry.metske@gmail.com designates 209.85.146.180 as permitted sender) Received: from [209.85.146.180] (HELO wa-out-1112.google.com) (209.85.146.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Oct 2008 11:36:23 +0000 Received: by wa-out-1112.google.com with SMTP id l24so249975waf.12 for ; Fri, 10 Oct 2008 04:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=ku58V4meVmhBm9lNOYngc8iHo+Bm1EMv5cgnneAn1c0=; b=mDMtO+4DdwgE89sRWKPG1gGXMZw52E6PPRMMrrqW157hpKBZp4M88GD/G2oMRGTHBi Z2Sx0teNawWi7EfpWW/qV6yWES5b09mvQnyh5VPDZckNpgJFuV1chiDOYhXhXPBlV2lc KSEzwdk5EjTiqIZRKcwzeLokH5nqJl1Apn1iQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=hqF6WN/I26/Uz1M7zo3KHgl3fAknAik2PI3KawEAC4O9TSShpMa8Ya8ADg+LMM9JFX ukad/Zei/ZiAqKxQiQcXcR3OhYBMPiIhtNVTpfhXHlVOMy9rE22cjxqDD2Nik9VRNXqa Hnla4g/M4XY1/kLUW0hQzgpCpLa/BqKhLUd/E= Received: by 10.114.46.11 with SMTP id t11mr1522554wat.211.1223638619411; Fri, 10 Oct 2008 04:36:59 -0700 (PDT) Received: by 10.114.149.20 with HTTP; Fri, 10 Oct 2008 04:36:59 -0700 (PDT) Message-ID: <3a6c97f00810100436r521d026dma692db2ae7c4a36b@mail.gmail.com> Date: Fri, 10 Oct 2008 13:36:59 +0200 From: "Harry Metske" To: jspwiki-user@incubator.apache.org Subject: Re: Upload Question In-Reply-To: <48EF1758.6010202@mail.upb.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_85752_21148359.1223638619385" References: <48EB74C8.7040909@mail.upb.de> <3a6c97f00810070933w1b14d1a1w66b0b983ad5a5d8c@mail.gmail.com> <48ECB104.5070609@mail.upb.de> <3a6c97f00810080851i30ffb214of724346a96774b96@mail.gmail.com> <48EE1582.3080602@mail.upb.de> <3a6c97f00810090915o2f8b37a9x42acbde393bc30a9@mail.gmail.com> <48EF1758.6010202@mail.upb.de> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_85752_21148359.1223638619385 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Benedikt, I think JSPWiki should offer the option to specify the enctype for the form, as I suggested yesterday. Can you file a JIRA issue ( https://issues.apache.org/jira/browse/JSPWIKI ) for this ? regards, Harry 2008/10/10 Benedikt Mohrmann > Hi, > > just checked it again. > The problem is definetely the form: > org.apache.commons.fileupload.FileUploadBase$InvalidContentTypeException: > the request doesn't contain a multipart/form-data or multipart/mixed stream, > content type header is application/x-www-form-urlencoded > > Pretty bad that you can not change the enctype. > In the Wiki Src it is: > tag.append( "\" method=\""+method+"\" > enctype=\"application/x-www-form-urlencoded\">\n" ); > > Can't I just change this? > > Another way could be to write a plugin with the following code (snippet): > returnStringBuffer.append("
"); > returnStringBuffer.append("
name=\"uploadForm\" accept-charset=\"UTF-8\" method=\"post\" > enctype=\"multipart/form-data\">"); > returnStringBuffer.append(" value=\"uploadForm\"/>"); > returnStringBuffer.append(" type=\"file\"> value=\"Hochladen\" />"); > returnStringBuffer.append("
"); > > This would create a form, but how can I tell the Wiki which plugin to use, > when the button is hit? > > Regards > Benedikt > > > Janne Jalkanen schrieb: > >> >> I think it is important to look into the cause... The stack trace would be >> important, yes. There could be many things failing. >> >> /Janne >> >> On Oct 9, 2008, at 19:15 , Harry Metske wrote: >> >> I think so too (multipart/form-data), but can you print the stacktrace >>> just >>> before returning " BUG" , maybe you'll get a clue then ? >>> >>> The FormOpen class currently has a hardcoded >>> "application/x-www-form-urlencoded", I think this should be >>> parameterizable >>> with the current value as the default. >>> >>> >>> regards, >>> Harry >>> >>> >>> 2008/10/9 Benedikt Mohrmann >>> >>> Hi, >>>> >>>> I tried a few things already, but did not get it to work so far. >>>> >>>> At first I created a new site, which contains: >>>> [{FormSet form='searchForm'}] >>>> [{FormOpen form='searchForm'}] >>>> [{FormInput type='file' name='searchInput'}] >>>> >>>> [{FormInput type='submit' name='submit' value='Submit'}] >>>> [{FormClose}] >>>> [{FormOutput form='searchForm' handler='MyTest2'}] >>>> >>>> Thus there is only a form where you can upload your data. >>>> >>>> The Plugin contains the following code (at this time really simple, just >>>> to >>>> check if it works): >>>> public class MyTest2 implements WikiPlugin { >>>> >>>> @Override >>>> public String execute(WikiContext context, Map params) throws >>>> PluginException { >>>> HttpServletRequest request = context.getHttpRequest(); >>>> boolean isMultipart = >>>> ServletFileUpload.isMultipartContent(request); >>>> // Create a factory for disk-based file items >>>> FileItemFactory factory = new DiskFileItemFactory(); >>>> >>>> // Create a new file upload handler >>>> ServletFileUpload upload = new ServletFileUpload(factory); >>>> >>>> // Parse the request >>>> List items = null; >>>> try { >>>> items = upload.parseRequest(request); >>>> } catch (Exception e) { >>>> // TODO Auto-generated catch block >>>> return "BUG"; >>>> } >>>> return "Works"; >>>> } >>>> } >>>> >>>> So far I always get the "BUG" output when I choose a file and hit the >>>> submitbutton. >>>> One problem could be that when I take a look at the produced HTML code, >>>> the >>>> form is introduced with: >>>> >>>>
>>> accept-charset="UTF-8" method="post" >>>> enctype="application/x-www-form-urlencoded"> >>>> >>>> I think it should be the enctype: multipart/form-data >>>> But I don't know if that is the point. >>>> >>>> Any other ideas? >>>> >>>> >>>> Best regards >>>> Benedikt >>>> >>>> >>>> >>>> >>>> >>>> Harry Metske schrieb: >>>> >>>> my previous answer was a bit too much in a hurry.... >>>>> >>>>> first your compile, Eclipse tells you there is no method getHttpRequest >>>>> for >>>>> a wiki context, that is strange, looking at the source it does have it >>>>> : >>>>> >>>>> ........ >>>>> /** >>>>> * If the request did originate from a HTTP request, >>>>> * then the HTTP request can be fetched here. However, it the >>>>> request >>>>> * did NOT originate from a HTTP request, then this method will >>>>> * return null, and YOU SHOULD CHECK FOR IT! >>>>> * >>>>> * @return Null, if no HTTP request was done. >>>>> * @since 2.0.13. >>>>> */ >>>>> public HttpServletRequest getHttpRequest() >>>>> { >>>>> return m_request; >>>>> } >>>>> ....... >>>>> >>>>> and if you can't compile it, I shouldn't even try to run it. >>>>> Maybe you can reply the complete source of your plugin ? >>>>> >>>>> regards, >>>>> Harry >>>>> >>>>> 2008/10/8 Benedikt Mohrmann >>>>> >>>>> >>>>> >>>>> Hi, >>>>>> >>>>>> thanks for your answer- I already had a look at commons fileupload. >>>>>> But the problem is, when I use: >>>>>> >>>>>> HttpServletRequest request = context.getHttpRequest(); >>>>>> >>>>>> JSPWiki tells me >>>>>> >>>>>> HttpServletRequest cannot be resolved to a type >>>>>> The type javax.servlet.http.HttpServletRequest cannot be resolved. >>>>>> >>>>>> In addition I am implementing my plugin in Eclipse and it tells me >>>>>> that >>>>>> there is no method getHttpRequest for a wiki context. >>>>>> >>>>>> Best regards >>>>>> Benedikt >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Harry Metske schrieb: >>>>>> >>>>>> Benedikt, >>>>>> >>>>>> >>>>>> in your plugin you have access to the HttpServletRequest ( >>>>>>> HttpServletRequest request = context.getHttpRequest(); ) . >>>>>>> Once you have this, I think you can use many samples/tools to handle >>>>>>> the >>>>>>> uploaded file, but maybe the best one is commons fileupload ( >>>>>>> http://commons.apache.org/fileupload/using.html), this binary jar is >>>>>>> already >>>>>>> in the JSPWiki distribution. >>>>>>> >>>>>>> regards, >>>>>>> Harry >>>>>>> >>>>>>> 2008/10/7 Benedikt Mohrmann >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>>> >>>>>>>> my intention is to upload a file via JSPWiki, but not as an >>>>>>>> attachment. >>>>>>>> >>>>>>>> I am trying to upload a file, thus I created a form containing a >>>>>>>> file >>>>>>>> chooser and a submitbutton. >>>>>>>> The goal is, that the input file is transferred to the server and >>>>>>>> then >>>>>>>> handled by a plugin I wrote. >>>>>>>> >>>>>>>> The plugin just puts the file as a Serializable into a database >>>>>>>> (which >>>>>>>> already works, when I read a file from my harddisk). >>>>>>>> But I am not yet not able to transfer the content of the file as a >>>>>>>> stream >>>>>>>> or something like that. >>>>>>>> >>>>>>>> Any experiences how this could work? >>>>>>>> >>>>>>>> Best regards >>>>>>>> Benedikt >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >> > ------=_Part_85752_21148359.1223638619385--