Re: Jakarta Struts Book Review Project
Many thanks. At 10:35 AM 4/19/02 +1000, you wrote: ** Note: This e-mail is subject to the disclaimer contained at the bottom of this message. ** : Hi there, FYI. http://www.theserverside.com/resources/strutsreview.jsp Regards Kelvin : The information transmitted in this message and attachments (if any) is intended only for the person or entity to which it is addressed. The message may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited. If you have received this in error, please contact the sender and delete this e-mail and associated material from any computer. The intended recipient of this e-mail may only use, reproduce, disclose or distribute the information contained in this e-mail and any attached files, with the permission of CGU Insurance. This message has been scanned for viruses and cleared by MailMarshal. : -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: multipart/form-data (bug?) or intended behavior?
Can't this multi-part request forward problem be fixed by unwrapping the request before doing RequestDispatcher.forward/include? All the methods in RequestProcessor get the real request object from within the MultipartRequestWrapper before calling doForward() or doInclude() except for processActionForward() which gets called after action.execute(). I think the if (request instanceof MultipartRequestWrapper) { request = ((MultipartRequestWrapper) request).getRequest(); } code should be moved to doForward() and doInclude() and removed everywhere else within RequestProcessor. I will try this fix today. Probably won't work because it seems too easy. Hal -Original Message- From: Adam P. Jenkins [mailto:[EMAIL PROTECTED]] Sent: Thu 4/18/2002 7:56 PM To: Struts Developers List Cc: Subject: Re: multipart/form-data (bug?) or intended behavior? Well, in your example scenario, you said that ActionOne first saves the multipart data to a file, and then forwards to ActionTwo, so there's no problem. When happens when a redirect forward is returned from an Action is as follows: - Struts sees that the redirect property of the ActionForward is true, so instead of just calling the next action in the same request, it sends a response back to the browser. The response contains a Redirect: header which contains the URL for ActionTwo. The browser sees the Redirect header and so makes a request for ActionTwo, this time with no multipart/form-data. The new request gets passed by struts directly to ActionTwo. Where the above would be a problem is if ActionOne did NOT handle the multipart data, but instead forwarded to ActionTwo expecting ActionTwo to handle the multipart data. Since a redirect causes a new request to be made, any data in the current request is lost by the time ActionTwo gets called. But since in this case ActionOne already handled the request, there's no real problem. Another example of where using a redirect forward is a problem is if your action saves some ActionMessages or ActionErrors in the request and then forwards, expecting the page being forwarded to to display the messages. Since ActionMessages are stored in the request object, if you returned a redirect forward from your action, the messages will be lost by the time the next page gets the request. Adam On Thursday 18 April 2002 01:14 pm, you wrote: Thats a pretty dirty workaround if your multipart request contained a 5MB file being uploaded. Or what occurs in that case (when the browser makes the new request)? Rob Adam P. Jenkins wrote: I believe another workaround is to set the redirect attribute on the forward to true. E.g. the action config for ActionOne would have a local forward like this: forward name=nextaction path=/action2.do redirect=true/ Then in ActionOne, when you return mapping.findForward(nextaction), this will cause the struts to send a redirect header to the browser telling it to make a new request for action2. This works fine unless you really wanted ActionTwo to have access to the same request attributes and parameters as ActionOne. Adam On Thursday 18 April 2002 08:47 am, rob wrote: It's been this way since struts 1.0 (and likely prior to) but http requests carrying multipart/form-data posts result in an exception being thrown if forwarded through more than one action. (e.g request flow) 1 - submit multipart/form-data request (with at least one file input) request is forwarded to ActionOne. 2 - ActionOne handles multipart data, writes a file to disk does something with other parameters etc. then forwards to ActionTwo. 3 - Exception is thrown. This occurs in the following versions I've tested 1.0.x, 1.1-b1. Copies of the exceptions follow this post. Workaround, never forward to a second action, always forward to a .jsp which must be the end point for the request after the first action. (This kind of sucks). If this is a bug then consider it submitted, if it's designed this way then how about changing it? (pretty please?) Thanks Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
File delete problem solved? Was: Re: Any news about Bug #3465 assigned to Mike Schachter?
Hi Mike, after sitting a long time staring at my code I found the bug which isn't a bug at all. If you say myFormFile.getInputStream() and then try to myFormFile.destroy() there must be an inputStream.close() inbetween. Otherwise there is an open file descriptor on the file and even JDK isn't able to delete it. Maybe this should be inserted in the javadoc of getInputStream method of FormFile and DiskFile !? I hope that I helped to solve that problem a little bit... Cheers from the lake of Constance, Germany, Jochen -- mailto:[EMAIL PROTECTED] \ in-integrierte informationssysteme GmbH \ Am Seerhein 8 Tel +49 (0)7531/8145-0 \ D-78467 Konstanz Fax -81 \ http://www.in-gmbh.de \ Von: SCHACHTER,MICHAEL (HP-NewJersey,ex2) [mailto:[EMAIL PROTECTED]] That bug's been around for a long time. The reason it remains there is because I've never been able to verify it; but I've seen the problem with the java.io.File.delete() method in the past with other projects. Have you verified that the bug exists in your application? -Original Message- From: Hans-Joachim Matheus [mailto:[EMAIL PROTECTED]] Sent: Friday, April 05, 2002 11:11 AM To: [EMAIL PROTECTED] Subject: Any news about Bug #3465 assigned to Mike Schachter? Hi, I wonder if there is any news about this bug? Maybe this has something to do with the path and the permission to delete a file? I wonder why first the ServletContext attribute javax.servlet.context.tempdir is used and if this is null then the Servlet Init Parameter tempDir is used and not vice versa. In Tomcat 3 the javax.servlet.context.tempdir is the dir where jasper compiles the jsps (i.e. the worker dir). Does this mean that struts has no permission to delete files in there? If I have a WebApp with many file uploads this is very bad because of an ever growing temp dir. Thanks for your hints... Hans-Joachim Matheus -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8304] New: - password tag in struts-html.tld twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8304. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8304 password tag in struts-html.tld twice Summary: password tag in struts-html.tld twice Product: Struts Version: Nightly Build Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] um, the subject pretty much says it all.. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]