Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 14036 invoked by uid 500); 17 May 2003 12:11:09 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 14019 invoked from network); 17 May 2003 12:11:08 -0000 Received: from unknown (HELO host.leverageweb.com) (64.91.232.157) by daedalus.apache.org with SMTP; 17 May 2003 12:11:08 -0000 Received: from 66-44-60-153.s153.tnt4.lnhva.md.dialup.rcn.com ([66.44.60.153] helo=geoff2k) by host.leverageweb.com with asmtp (Exim 3.36 #1) id 19H0Tl-0000PX-00 for cocoon-dev@xml.apache.org; Sat, 17 May 2003 08:07:58 -0400 From: "Geoff Howard" To: Subject: RE: upload problem (WAS: RE: How to use the file uploading mechanism in cocoon) Date: Sat, 17 May 2003 08:29:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <000f01c31c6a$8b4a7690$0801a8c0@Lagrange> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.leverageweb.com X-AntiAbuse: Original Domain - xml.apache.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - leverageweb.com X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > -----Original Message----- > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] > > -----Original Message----- > > From: Geoff Howard [mailto:cocoon@leverageweb.com] > > > > This makes the cleanup fail on CocoonServlet:1209. > > Does it? Since the instanceof test is done against the object returned > from the requestFactory: > > 1045: if (this.enableUploads) { > request = requestFactory.getServletRequest(req); > } else { > request = req; > } > > Which makes request a MultipartHttpServletRequest. So: > > 1209: if (request instanceof MultipartHttpServletRequest) { > ((MultipartHttpServletRequest) request).cleanup(); > } > > Should be invoked properly. Yes, I think you're right - I noticed this last night when I went back to look at CocoonServlet. (The first call I mentioned still won't work though). What's weird is that I thought I have confirmed that the cleanup is not happening. I'll look at that more carefully. > > What about exposing something like boolean isMultiPart()? > > What about exposing a dispose() method instead? In a request-response > environment it makes sense to have an explicit disposal point. We have to clarify where. I assume you mean (as I did) to expose that on the environment's wrapper around the request. I'd be perfectly happy with that - The environment has the real request, and so can do the instanceof test, and can determine if MultipartHttpServletRequest.cleanup() can be called. So, +1 from me? Geoff