RE: Parsing multipart form data
Hi Collin, don't worry. I had the same problem with Cocoon 2.0.2. There is a bug in it. Use a later version and it will work. Best regards - Volker - -Original Message-From: Collin VanDyck [mailto:[EMAIL PROTECTED]]Sent: Montag, 20. Januar 2003 21:36To: [EMAIL PROTECTED]Subject: Parsing multipart form data Hi, I'm trying to figure out the best way to parse multi-part form data. I have a page which submits to a certain URI which invokes an action. This action needs to parse the multi-part form data (in the request object I believe) and then pass that data off to my j2ee backend for processing. My problem is that I do not see a way for me to create this MultipartParser or what not. The Cocoon request object does not as I understand it, provide a way for me to get the necessary data to create this parser (i.e. I need a HttpServletRequest), and since my editor does not implement the servlet interface, it does not receive the Request object from the servlet container as a parameter (i.e. doAction, etc). I feel like I am possibly barking up the wrong tree here. Is the action the appropriate place to do this? Should I instead implement a matcher to find this request object? thanks, Collin Collin VanDyckAOL: djtclYahoo: webcollin
Re: Parsing multipart form data
Geoff Ok, everything is working now. Strangely, I had in addition to my cocoon-2.0.4.jar, a rogue cocoon-2.0.2 which I believe was getting deployed first or with priority by my container. Argh. Thanks for your help! Everything is working perfectly now. Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 7:27 PM Subject: RE: Parsing multipart form data Hi Geoff, When I cast directly to FilePartArray I get a ClassCastException, which I thought was due to Cocoon not receiving the init-param correctly. Is that normal? Collin That sounds right. Change it back to FilePartArray of course. So, back to web.xml/cocoon version for the culprit? - Since you have three web.xml files (one per webapp), make sure you're changing the same one you're testing on (or all three). - Make sure you restart after modifying web.xml. - Confirm what version of cocoon you're using - how did you get 2.0.4? What is the date of the main cocoon jar? Geoff - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:37 PM Subject: RE: Parsing multipart form data There you go - you've cast to FilePartFile - cast to FilePart (or directly to FilePartArray) and you're set. We need another example at the Wiki (assuming that's where you got the concept from?) showing FilePartArray. Should have thought of that first, Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:22 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Hi Geoff. Here's really the only thing I'm doing with it right now. FilePartFile fpf = (FilePartFile)request.get(file_content); log.info(received file of name: + fpf.getFileName()); thanks,-- Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:32 PM Subject: RE: Parsing multipart form data ah, that brings to mind another idea - send a snippet of your action that deals with getting the FilePart... Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Here is my web.xml file. (It's long, so an apology in advance). I hope this helps, and I really do appreciate everyone's help in this list. I commented out overwrite-uploads and set the autosave-uploads to false, but I still get a FilePartFile instead of a FilePartArray. thanks, Collin ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameContentXML web app/display-name descriptionProvides the administration interface to the ContentXML System/description servlet servlet-nameCocoon2/servlet-name display-nameCocoon2/display-name descriptionThe main Cocoon2 servlet/description !-- In cases you're facing class loader problems you can alternatively use the following servlet-class instead of the normal one servlet-classorg.apache.cocoon.servlet.ParanoidCocoonServlet/se rvlet-clas s -- servlet-classorg.apache.cocoon.servlet.CocoonServlet/servlet-class !-- This parameter points to the main configuration file for Cocoon. Note that the path is specified in absolute notation but it will be resolved relative to the servlets webapp context path -- init-param param-nameconfigurations/param-name param-value/WEB-INF/cocoon.xconf/param-value /init-param !-- This parameter tells cocoon to set the thread's context classloader to its own classloader. If you experience strange classloader issues, try setting this parameter to true or using ParanoidCocoonServlet. -- init-param param-nameinit-classloader/param-name param-valuefalse/param-value /init-param !-- This parameter indicates the configuration file of the LogKit management -- init-param param-namelogkit-config/param-name param-value/WEB-INF/logkit.xconf/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit configuration used by the CocoonServlet. -- init-param param-nameservlet-logger/param-name param-valueaccess/param-value /init-param !-- This parameter indicates the category id of the logger from
RE: Parsing multipart form data
That explains alot. Thanks for reporting back. Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 5:14 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Geoff Ok, everything is working now. Strangely, I had in addition to my cocoon-2.0.4.jar, a rogue cocoon-2.0.2 which I believe was getting deployed first or with priority by my container. Argh. Thanks for your help! Everything is working perfectly now. Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 7:27 PM Subject: RE: Parsing multipart form data Hi Geoff, When I cast directly to FilePartArray I get a ClassCastException, which I thought was due to Cocoon not receiving the init-param correctly. Is that normal? Collin That sounds right. Change it back to FilePartArray of course. So, back to web.xml/cocoon version for the culprit? - Since you have three web.xml files (one per webapp), make sure you're changing the same one you're testing on (or all three). - Make sure you restart after modifying web.xml. - Confirm what version of cocoon you're using - how did you get 2.0.4? What is the date of the main cocoon jar? Geoff - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:37 PM Subject: RE: Parsing multipart form data There you go - you've cast to FilePartFile - cast to FilePart (or directly to FilePartArray) and you're set. We need another example at the Wiki (assuming that's where you got the concept from?) showing FilePartArray. Should have thought of that first, Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:22 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Hi Geoff. Here's really the only thing I'm doing with it right now. FilePartFile fpf = (FilePartFile)request.get(file_content); log.info(received file of name: + fpf.getFileName()); thanks,-- Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:32 PM Subject: RE: Parsing multipart form data ah, that brings to mind another idea - send a snippet of your action that deals with getting the FilePart... Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Here is my web.xml file. (It's long, so an apology in advance). I hope this helps, and I really do appreciate everyone's help in this list. I commented out overwrite-uploads and set the autosave-uploads to false, but I still get a FilePartFile instead of a FilePartArray. thanks, Collin ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameContentXML web app/display-name descriptionProvides the administration interface to the ContentXML System/description servlet servlet-nameCocoon2/servlet-name display-nameCocoon2/display-name descriptionThe main Cocoon2 servlet/description !-- In cases you're facing class loader problems you can alternatively use the following servlet-class instead of the normal one servlet-classorg.apache.cocoon.servlet.ParanoidCocoonServlet/se rvlet-clas s -- servlet-classorg.apache.cocoon.servlet.CocoonServlet/servlet-class !-- This parameter points to the main configuration file for Cocoon. Note that the path is specified in absolute notation but it will be resolved relative to the servlets webapp context path -- init-param param-nameconfigurations/param-name param-value/WEB-INF/cocoon.xconf/param-value /init-param !-- This parameter tells cocoon to set the thread's context classloader to its own classloader. If you experience strange classloader issues, try setting this parameter to true or using ParanoidCocoonServlet. -- init-param param-nameinit-classloader/param-name param-valuefalse/param-value /init-param !-- This parameter indicates the configuration file of the LogKit management -- init-param param-namelogkit-config/param
Parsing multipart form data
Hi, I'm trying to figure out the best way to parse multi-part form data. I have a page which submits to a certain URI which invokes an action. This action needs to parse the multi-part form data (in the request object I believe) and then pass that data off to my j2ee backend for processing. My problem is that I do not see a way for me to create this MultipartParser or what not. The Cocoon request object does not as I understand it, provide a way for me to get the necessary data to create this parser (i.e. I need a HttpServletRequest), and since my editor does not implement the servlet interface, it does not receive the Request object from the servlet container as a parameter (i.e. doAction, etc). I feel like I am possibly barking up the wrong tree here. Is the action the appropriate place to do this? Should I instead implement a matcher to find this request object? thanks, Collin Collin VanDyckAOL: djtclYahoo: webcollin
RE: Parsing multipart form data
Have you seen this document yet? http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithCocoon. I'm sorry if it's not written very clearly - I wrote it late at night sort of spontaneously. That gives some basic information on how cocoon handles things behind the scenes. The important part in your case is that you don't need to do the multipart parsing - it's already done for you by the time your action gets on the scene. You can then use the FilePart object to get the contents of the file via an InputStream and do whatever you want with it. If that doesn't help, give more of an idea of what you need to do on the backend. Geoff Howard -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 3:36 PM To: [EMAIL PROTECTED] Subject: Parsing multipart form data Hi, I'm trying to figure out the best way to parse multi-part form data. I have a page which submits to a certain URI which invokes an action. This action needs to parse the multi-part form data (in the request object I believe) and then pass that data off to my j2ee backend for processing. My problem is that I do not see a way for me to create this MultipartParser or what not. The Cocoon request object does not as I understand it, provide a way for me to get the necessary data to create this parser (i.e. I need a HttpServletRequest), and since my editor does not implement the servlet interface, it does not receive the Request object from the servlet container as a parameter (i.e. doAction, etc). I feel like I am possibly barking up the wrong tree here. Is the action the appropriate place to do this? Should I instead implement a matcher to find this request object? thanks, Collin Collin VanDyck AOL: djtcl Yahoo: webcollin - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Parsing multipart form data
Thanks Geoff Well, yes, I actually started going thru the mail lists and found your link below. It is helpful, but I cannot get some of the features to work. I DO have the FilePartFile bit working, though I would not like to store such files on the disk. I gave these two init params: init-param param-nameautosave-uploads/param-name param-valuefalse/param-value /init-param init-param param-nameoverwrite-uploads/param-name param-valueallow/param-value /init-param I basically want to keep them in memory, and then use a FilePartArray to save the file contents into the database, but I am having trouble with that. Cocoon does not seem to be recognizing these parameters. Incidentally, I am using 2.0.4, and I built it under java1.4. I put the init-params with the other init-params in web.xml, but strangely did not see any places for it in the web.xml file as it existed. I thouight there would be placeholders for it, but I could not find them. Anyways, I might be missing something. My main problem now is that when I submit a file multiple times, it keeps renaming the file 0_[filename], 1_[filename], etc.. I think my workaround will be to just delete the file once I am done with it, but I would like to keep it in memory if at all possible. Thanks very much for your help! Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 4:01 PM Subject: RE: Parsing multipart form data Have you seen this document yet? http://wiki.cocoondev.org/Wiki.jsp?page=FileUploadsWithCocoon. I'm sorry if it's not written very clearly - I wrote it late at night sort of spontaneously. That gives some basic information on how cocoon handles things behind the scenes. The important part in your case is that you don't need to do the multipart parsing - it's already done for you by the time your action gets on the scene. You can then use the FilePart object to get the contents of the file via an InputStream and do whatever you want with it. If that doesn't help, give more of an idea of what you need to do on the backend. Geoff Howard -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 3:36 PM To: [EMAIL PROTECTED] Subject: Parsing multipart form data Hi, I'm trying to figure out the best way to parse multi-part form data. I have a page which submits to a certain URI which invokes an action. This action needs to parse the multi-part form data (in the request object I believe) and then pass that data off to my j2ee backend for processing. My problem is that I do not see a way for me to create this MultipartParser or what not. The Cocoon request object does not as I understand it, provide a way for me to get the necessary data to create this parser (i.e. I need a HttpServletRequest), and since my editor does not implement the servlet interface, it does not receive the Request object from the servlet container as a parameter (i.e. doAction, etc). I feel like I am possibly barking up the wrong tree here. Is the action the appropriate place to do this? Should I instead implement a matcher to find this request object? thanks, Collin Collin VanDyck AOL: djtcl Yahoo: webcollin - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Parsing multipart form data
Here is my web.xml file. (It's long, so an apology in advance). I hope this helps, and I really do appreciate everyone's help in this list. I commented out overwrite-uploads and set the autosave-uploads to false, but I still get a FilePartFile instead of a FilePartArray. thanks, Collin ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameContentXML web app/display-name descriptionProvides the administration interface to the ContentXML System/description servlet servlet-nameCocoon2/servlet-name display-nameCocoon2/display-name descriptionThe main Cocoon2 servlet/description !-- In cases you're facing class loader problems you can alternatively use the following servlet-class instead of the normal one servlet-classorg.apache.cocoon.servlet.ParanoidCocoonServlet/servlet-clas s -- servlet-classorg.apache.cocoon.servlet.CocoonServlet/servlet-class !-- This parameter points to the main configuration file for Cocoon. Note that the path is specified in absolute notation but it will be resolved relative to the servlets webapp context path -- init-param param-nameconfigurations/param-name param-value/WEB-INF/cocoon.xconf/param-value /init-param !-- This parameter tells cocoon to set the thread's context classloader to its own classloader. If you experience strange classloader issues, try setting this parameter to true or using ParanoidCocoonServlet. -- init-param param-nameinit-classloader/param-name param-valuefalse/param-value /init-param !-- This parameter indicates the configuration file of the LogKit management -- init-param param-namelogkit-config/param-name param-value/WEB-INF/logkit.xconf/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit configuration used by the CocoonServlet. -- init-param param-nameservlet-logger/param-name param-valueaccess/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit management configuration for the Cocoon engine. This logger is used for all components described in the cocoon.xconf and sitemap.xmap file not having specified a logger with the logger=... attribute in the component configuration file. -- init-param param-namecocoon-logger/param-name param-valuecore/param-value /init-param !-- This parameter indicates the log level to use throughout startup of the system. As soon as the logkit.xconf the setting of the logkit.xconf configuration is used instead! Only for startup and if the logkit.xconf is not readable/available this log level is of importance. Available levels are: DEBUG: prints all level of log messages. INFO: prints all level of log messages except DEBUG ones. WARN: prints all level of log messages except DEBUG and INFO ones. ERROR: prints all level of log messages except DEBUG, INFO and WARN ones. FATAL_ERROR: prints only log messages of this level -- init-param param-namelog-level/param-name param-valueINFO/param-value /init-param !-- Allow reinstantiating (reloading) of the cocoon instance. If this is set to yes or true, a new cocoon instance can be created using the request parameter cocoon-reload. -- init-param param-nameallow-reload/param-name param-valueyes/param-value /init-param !-- This parameter is used to list classes that should be loaded at initialization time of the servlet. Usually this classes are JDBC Drivers used -- init-param param-nameload-class/param-name param-value !-- For IBM WebSphere: com.ibm.servlet.classloader.Handler -- !-- For Database Driver: -- org.hsqldb.jdbcDriver !-- For parent ComponentManager sample: org.apache.cocoon.samples.parentcm.Configurator -- /param-value /init-param !-- This parameter allows to specify where Cocoon should put uploaded files. The path specified can be either absolute or relative to the context path of the servlet. On windows platform, absolute directory must start with volume: C:\Path\To\Upload\Directory The default directory is upload-dir in the work-directory init-param param-nameupload-directory/param-name param-valueWEB-INF/work/upload-dir/param-value /init-param -- !-- Causes all files in multipart requests to be saved to upload-dir. Default is true. Unsupported values will be interpreted as false. -- init-param param-nameautosave-uploads/param-name param-valuefalse/param-value /init-param !-- Specify handling of name conflicts when saving uploaded files to disk. Acceptable values are deny, allow, rename (default). Files are renamed x_filename where x is an integer value incremented to make the new filename unique. init-param param-nameoverwrite-uploads/param-name param-valueallow/param-value /init-param -- !-- Specify maximum allowed size of the upload. Defaults to 10 Mb. init-param param-nameupload-max-size/param-name param-value1000/param-value /init-param -- !-- This parameter allows to specify where Cocoon should create its page and other objects cache. The path specified
RE: Parsing multipart form data
sounds to me like something is wrong with your web.xml (more below): Thanks Geoff Well, yes, I actually started going thru the mail lists and found your link below. It is helpful, but I cannot get some of the features to work. I DO have the FilePartFile bit working, though I would not like to store such files on the disk. I gave these two init params: init-param param-nameautosave-uploads/param-name param-valuefalse/param-value /init-param init-param param-nameoverwrite-uploads/param-name param-valueallow/param-value /init-param That looks fine... where did you put them? I basically want to keep them in memory, and then use a FilePartArray to save the file contents into the database, but I am having trouble with that. Cocoon does not seem to be recognizing these parameters. Incidentally, I am using 2.0.4, and I built it under java1.4. Ok, you should not have problems then. I put the init-params with the other init-params in web.xml, but strangely did not see any places for it in the web.xml file as it existed. I thouight there would be placeholders for it, but I could not find them. That's what I find weird. They're all in web.xml as you can see here: http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/webapp/WEB-INF/ web.xml?rev=1.8.2.5only_with_tag=cocoon_2_0_4 Sanity check: - You did modify the web.xml in cocoon/WEB-INF/ right? (not the one the one in the servlet container/Tomcat conf directory?) - Did you do a search for them using an editor? If searching for the string autosave-uploads is not turning anything up, something's wrong. - Did you restart the servlet container/cocoon? - How did you obtain 2.0.4? (you're sure it's not 2.0.3?) Anyways, I might be missing something. My main problem now is that when I submit a file multiple times, it keeps renaming the file 0_[filename], 1_[filename], You are seeing the (what used to be) default behavior - uploads are autosaved to disk, and filename conflicts are renamed (bad race condition there at one point so beware). This makes me think you're using 2.0.3? etc.. I think my workaround will be to just delete the file once I am done with it, but I would like to keep it in memory if at all possible. That works as well (actually I'd love to see a third option for autosave-uploads: temp which would delete the file after the servlet finishes processing. Haven't been able to look into it yet (any volunteers?) Thanks very much for your help! Collin No problem. Geoff - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parsing multipart form data
ah, that brings to mind another idea - send a snippet of your action that deals with getting the FilePart... Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Here is my web.xml file. (It's long, so an apology in advance). I hope this helps, and I really do appreciate everyone's help in this list. I commented out overwrite-uploads and set the autosave-uploads to false, but I still get a FilePartFile instead of a FilePartArray. thanks, Collin ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameContentXML web app/display-name descriptionProvides the administration interface to the ContentXML System/description servlet servlet-nameCocoon2/servlet-name display-nameCocoon2/display-name descriptionThe main Cocoon2 servlet/description !-- In cases you're facing class loader problems you can alternatively use the following servlet-class instead of the normal one servlet-classorg.apache.cocoon.servlet.ParanoidCocoonServlet/se rvlet-clas s -- servlet-classorg.apache.cocoon.servlet.CocoonServlet/servlet-class !-- This parameter points to the main configuration file for Cocoon. Note that the path is specified in absolute notation but it will be resolved relative to the servlets webapp context path -- init-param param-nameconfigurations/param-name param-value/WEB-INF/cocoon.xconf/param-value /init-param !-- This parameter tells cocoon to set the thread's context classloader to its own classloader. If you experience strange classloader issues, try setting this parameter to true or using ParanoidCocoonServlet. -- init-param param-nameinit-classloader/param-name param-valuefalse/param-value /init-param !-- This parameter indicates the configuration file of the LogKit management -- init-param param-namelogkit-config/param-name param-value/WEB-INF/logkit.xconf/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit configuration used by the CocoonServlet. -- init-param param-nameservlet-logger/param-name param-valueaccess/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit management configuration for the Cocoon engine. This logger is used for all components described in the cocoon.xconf and sitemap.xmap file not having specified a logger with the logger=... attribute in the component configuration file. -- init-param param-namecocoon-logger/param-name param-valuecore/param-value /init-param !-- This parameter indicates the log level to use throughout startup of the system. As soon as the logkit.xconf the setting of the logkit.xconf configuration is used instead! Only for startup and if the logkit.xconf is not readable/available this log level is of importance. Available levels are: DEBUG: prints all level of log messages. INFO: prints all level of log messages except DEBUG ones. WARN: prints all level of log messages except DEBUG and INFO ones. ERROR: prints all level of log messages except DEBUG, INFO and WARN ones. FATAL_ERROR: prints only log messages of this level -- init-param param-namelog-level/param-name param-valueINFO/param-value /init-param !-- Allow reinstantiating (reloading) of the cocoon instance. If this is set to yes or true, a new cocoon instance can be created using the request parameter cocoon-reload. -- init-param param-nameallow-reload/param-name param-valueyes/param-value /init-param !-- This parameter is used to list classes that should be loaded at initialization time of the servlet. Usually this classes are JDBC Drivers used -- init-param param-nameload-class/param-name param-value !-- For IBM WebSphere: com.ibm.servlet.classloader.Handler -- !-- For Database Driver: -- org.hsqldb.jdbcDriver !-- For parent ComponentManager sample: org.apache.cocoon.samples.parentcm.Configurator -- /param-value /init-param !-- This parameter allows to specify where Cocoon should put uploaded files. The path specified can be either absolute or relative to the context path of the servlet. On windows platform, absolute directory must start with volume: C:\Path\To\Upload\Directory The default directory is upload-dir in the work-directory init-param param-nameupload-directory/param-name param-valueWEB-INF/work/upload-dir/param-value /init-param -- !-- Causes all files in multipart requests to be saved to upload-dir. Default is true. Unsupported values will be interpreted as false. -- init-param param-nameautosave-uploads/param-name param-valuefalse/param-value /init-param !-- Specify handling of name conflicts when saving uploaded files to disk. Acceptable values are deny, allow, rename (default). Files are renamed x_filename where
Re: Parsing multipart form data
Hi Geoff. Here's really the only thing I'm doing with it right now. FilePartFile fpf = (FilePartFile)request.get(file_content); log.info(received file of name: + fpf.getFileName()); thanks,-- Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:32 PM Subject: RE: Parsing multipart form data ah, that brings to mind another idea - send a snippet of your action that deals with getting the FilePart... Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Here is my web.xml file. (It's long, so an apology in advance). I hope this helps, and I really do appreciate everyone's help in this list. I commented out overwrite-uploads and set the autosave-uploads to false, but I still get a FilePartFile instead of a FilePartArray. thanks, Collin ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameContentXML web app/display-name descriptionProvides the administration interface to the ContentXML System/description servlet servlet-nameCocoon2/servlet-name display-nameCocoon2/display-name descriptionThe main Cocoon2 servlet/description !-- In cases you're facing class loader problems you can alternatively use the following servlet-class instead of the normal one servlet-classorg.apache.cocoon.servlet.ParanoidCocoonServlet/se rvlet-clas s -- servlet-classorg.apache.cocoon.servlet.CocoonServlet/servlet-class !-- This parameter points to the main configuration file for Cocoon. Note that the path is specified in absolute notation but it will be resolved relative to the servlets webapp context path -- init-param param-nameconfigurations/param-name param-value/WEB-INF/cocoon.xconf/param-value /init-param !-- This parameter tells cocoon to set the thread's context classloader to its own classloader. If you experience strange classloader issues, try setting this parameter to true or using ParanoidCocoonServlet. -- init-param param-nameinit-classloader/param-name param-valuefalse/param-value /init-param !-- This parameter indicates the configuration file of the LogKit management -- init-param param-namelogkit-config/param-name param-value/WEB-INF/logkit.xconf/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit configuration used by the CocoonServlet. -- init-param param-nameservlet-logger/param-name param-valueaccess/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit management configuration for the Cocoon engine. This logger is used for all components described in the cocoon.xconf and sitemap.xmap file not having specified a logger with the logger=... attribute in the component configuration file. -- init-param param-namecocoon-logger/param-name param-valuecore/param-value /init-param !-- This parameter indicates the log level to use throughout startup of the system. As soon as the logkit.xconf the setting of the logkit.xconf configuration is used instead! Only for startup and if the logkit.xconf is not readable/available this log level is of importance. Available levels are: DEBUG: prints all level of log messages. INFO: prints all level of log messages except DEBUG ones. WARN: prints all level of log messages except DEBUG and INFO ones. ERROR: prints all level of log messages except DEBUG, INFO and WARN ones. FATAL_ERROR: prints only log messages of this level -- init-param param-namelog-level/param-name param-valueINFO/param-value /init-param !-- Allow reinstantiating (reloading) of the cocoon instance. If this is set to yes or true, a new cocoon instance can be created using the request parameter cocoon-reload. -- init-param param-nameallow-reload/param-name param-valueyes/param-value /init-param !-- This parameter is used to list classes that should be loaded at initialization time of the servlet. Usually this classes are JDBC Drivers used -- init-param param-nameload-class/param-name param-value !-- For IBM WebSphere: com.ibm.servlet.classloader.Handler -- !-- For Database Driver: -- org.hsqldb.jdbcDriver !-- For parent ComponentManager sample: org.apache.cocoon.samples.parentcm.Configurator -- /param-value /init-param !-- This parameter allows to specify where Cocoon should put uploaded files. The path specified can be either absolute or relative to the context path of the servlet. On windows platform, absolute directory must start with volume: C:\Path\To\Upload\Directory The default directory is upload-dir in the work-directory
Re: Parsing multipart form data
Well, with regards to which web.xml file we are using. I am not sure why this is the way it is, but we have three WAR files, right now exploded, so they aren't archived (read: easy to modify).. Each of the WARs has its own web.xml file with a web-app tag that deals with Cocoon for that web application. Does that sound reasonable? Or would it be looking for the web.xml in the cocoon[something].jar? Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:32 PM Subject: RE: Parsing multipart form data sounds to me like something is wrong with your web.xml (more below): Thanks Geoff Well, yes, I actually started going thru the mail lists and found your link below. It is helpful, but I cannot get some of the features to work. I DO have the FilePartFile bit working, though I would not like to store such files on the disk. I gave these two init params: init-param param-nameautosave-uploads/param-name param-valuefalse/param-value /init-param init-param param-nameoverwrite-uploads/param-name param-valueallow/param-value /init-param That looks fine... where did you put them? I basically want to keep them in memory, and then use a FilePartArray to save the file contents into the database, but I am having trouble with that. Cocoon does not seem to be recognizing these parameters. Incidentally, I am using 2.0.4, and I built it under java1.4. Ok, you should not have problems then. I put the init-params with the other init-params in web.xml, but strangely did not see any places for it in the web.xml file as it existed. I thouight there would be placeholders for it, but I could not find them. That's what I find weird. They're all in web.xml as you can see here: http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-cocoon2/src/webapp/WEB-INF/ web.xml?rev=1.8.2.5only_with_tag=cocoon_2_0_4 Sanity check: - You did modify the web.xml in cocoon/WEB-INF/ right? (not the one the one in the servlet container/Tomcat conf directory?) - Did you do a search for them using an editor? If searching for the string autosave-uploads is not turning anything up, something's wrong. - Did you restart the servlet container/cocoon? - How did you obtain 2.0.4? (you're sure it's not 2.0.3?) Anyways, I might be missing something. My main problem now is that when I submit a file multiple times, it keeps renaming the file 0_[filename], 1_[filename], You are seeing the (what used to be) default behavior - uploads are autosaved to disk, and filename conflicts are renamed (bad race condition there at one point so beware). This makes me think you're using 2.0.3? etc.. I think my workaround will be to just delete the file once I am done with it, but I would like to keep it in memory if at all possible. That works as well (actually I'd love to see a third option for autosave-uploads: temp which would delete the file after the servlet finishes processing. Haven't been able to look into it yet (any volunteers?) Thanks very much for your help! Collin No problem. Geoff - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parsing multipart form data
There you go - you've cast to FilePartFile - cast to FilePart (or directly to FilePartArray) and you're set. We need another example at the Wiki (assuming that's where you got the concept from?) showing FilePartArray. Should have thought of that first, Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:22 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Hi Geoff. Here's really the only thing I'm doing with it right now. FilePartFile fpf = (FilePartFile)request.get(file_content); log.info(received file of name: + fpf.getFileName()); thanks,-- Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:32 PM Subject: RE: Parsing multipart form data ah, that brings to mind another idea - send a snippet of your action that deals with getting the FilePart... Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Here is my web.xml file. (It's long, so an apology in advance). I hope this helps, and I really do appreciate everyone's help in this list. I commented out overwrite-uploads and set the autosave-uploads to false, but I still get a FilePartFile instead of a FilePartArray. thanks, Collin ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameContentXML web app/display-name descriptionProvides the administration interface to the ContentXML System/description servlet servlet-nameCocoon2/servlet-name display-nameCocoon2/display-name descriptionThe main Cocoon2 servlet/description !-- In cases you're facing class loader problems you can alternatively use the following servlet-class instead of the normal one servlet-classorg.apache.cocoon.servlet.ParanoidCocoonServlet/se rvlet-clas s -- servlet-classorg.apache.cocoon.servlet.CocoonServlet/servlet-class !-- This parameter points to the main configuration file for Cocoon. Note that the path is specified in absolute notation but it will be resolved relative to the servlets webapp context path -- init-param param-nameconfigurations/param-name param-value/WEB-INF/cocoon.xconf/param-value /init-param !-- This parameter tells cocoon to set the thread's context classloader to its own classloader. If you experience strange classloader issues, try setting this parameter to true or using ParanoidCocoonServlet. -- init-param param-nameinit-classloader/param-name param-valuefalse/param-value /init-param !-- This parameter indicates the configuration file of the LogKit management -- init-param param-namelogkit-config/param-name param-value/WEB-INF/logkit.xconf/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit configuration used by the CocoonServlet. -- init-param param-nameservlet-logger/param-name param-valueaccess/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit management configuration for the Cocoon engine. This logger is used for all components described in the cocoon.xconf and sitemap.xmap file not having specified a logger with the logger=... attribute in the component configuration file. -- init-param param-namecocoon-logger/param-name param-valuecore/param-value /init-param !-- This parameter indicates the log level to use throughout startup of the system. As soon as the logkit.xconf the setting of the logkit.xconf configuration is used instead! Only for startup and if the logkit.xconf is not readable/available this log level is of importance. Available levels are: DEBUG: prints all level of log messages. INFO: prints all level of log messages except DEBUG ones. WARN: prints all level of log messages except DEBUG and INFO ones. ERROR: prints all level of log messages except DEBUG, INFO and WARN ones. FATAL_ERROR: prints only log messages of this level -- init-param param-namelog-level/param-name param-valueINFO/param-value /init-param !-- Allow reinstantiating (reloading) of the cocoon instance. If this is set to yes or true, a new cocoon instance can be created using the request parameter cocoon-reload. -- init-param param-nameallow-reload/param-name param-valueyes/param-value /init-param !-- This parameter is used to list classes that should be loaded at initialization time of the servlet. Usually this classes are JDBC Drivers used -- init-param param-nameload-class/param-name
Re: Parsing multipart form data
Hi Geoff, When I cast directly to FilePartArray I get a ClassCastException, which I thought was due to Cocoon not receiving the init-param correctly. Is that normal? Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:37 PM Subject: RE: Parsing multipart form data There you go - you've cast to FilePartFile - cast to FilePart (or directly to FilePartArray) and you're set. We need another example at the Wiki (assuming that's where you got the concept from?) showing FilePartArray. Should have thought of that first, Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:22 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Hi Geoff. Here's really the only thing I'm doing with it right now. FilePartFile fpf = (FilePartFile)request.get(file_content); log.info(received file of name: + fpf.getFileName()); thanks,-- Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:32 PM Subject: RE: Parsing multipart form data ah, that brings to mind another idea - send a snippet of your action that deals with getting the FilePart... Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Here is my web.xml file. (It's long, so an apology in advance). I hope this helps, and I really do appreciate everyone's help in this list. I commented out overwrite-uploads and set the autosave-uploads to false, but I still get a FilePartFile instead of a FilePartArray. thanks, Collin ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameContentXML web app/display-name descriptionProvides the administration interface to the ContentXML System/description servlet servlet-nameCocoon2/servlet-name display-nameCocoon2/display-name descriptionThe main Cocoon2 servlet/description !-- In cases you're facing class loader problems you can alternatively use the following servlet-class instead of the normal one servlet-classorg.apache.cocoon.servlet.ParanoidCocoonServlet/se rvlet-clas s -- servlet-classorg.apache.cocoon.servlet.CocoonServlet/servlet-class !-- This parameter points to the main configuration file for Cocoon. Note that the path is specified in absolute notation but it will be resolved relative to the servlets webapp context path -- init-param param-nameconfigurations/param-name param-value/WEB-INF/cocoon.xconf/param-value /init-param !-- This parameter tells cocoon to set the thread's context classloader to its own classloader. If you experience strange classloader issues, try setting this parameter to true or using ParanoidCocoonServlet. -- init-param param-nameinit-classloader/param-name param-valuefalse/param-value /init-param !-- This parameter indicates the configuration file of the LogKit management -- init-param param-namelogkit-config/param-name param-value/WEB-INF/logkit.xconf/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit configuration used by the CocoonServlet. -- init-param param-nameservlet-logger/param-name param-valueaccess/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit management configuration for the Cocoon engine. This logger is used for all components described in the cocoon.xconf and sitemap.xmap file not having specified a logger with the logger=... attribute in the component configuration file. -- init-param param-namecocoon-logger/param-name param-valuecore/param-value /init-param !-- This parameter indicates the log level to use throughout startup of the system. As soon as the logkit.xconf the setting of the logkit.xconf configuration is used instead! Only for startup and if the logkit.xconf is not readable/available this log level is of importance. Available levels are: DEBUG: prints all level of log messages. INFO: prints all level of log messages except DEBUG ones. WARN: prints all level of log messages except DEBUG and INFO ones. ERROR: prints all level of log messages except DEBUG, INFO and WARN ones. FATAL_ERROR: prints only log messages of this level -- init-param param-namelog-level/param-name param-valueINFO/param-value /init-param
RE: Parsing multipart form data
Hi Geoff, When I cast directly to FilePartArray I get a ClassCastException, which I thought was due to Cocoon not receiving the init-param correctly. Is that normal? Collin That sounds right. Change it back to FilePartArray of course. So, back to web.xml/cocoon version for the culprit? - Since you have three web.xml files (one per webapp), make sure you're changing the same one you're testing on (or all three). - Make sure you restart after modifying web.xml. - Confirm what version of cocoon you're using - how did you get 2.0.4? What is the date of the main cocoon jar? Geoff - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:37 PM Subject: RE: Parsing multipart form data There you go - you've cast to FilePartFile - cast to FilePart (or directly to FilePartArray) and you're set. We need another example at the Wiki (assuming that's where you got the concept from?) showing FilePartArray. Should have thought of that first, Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:22 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Hi Geoff. Here's really the only thing I'm doing with it right now. FilePartFile fpf = (FilePartFile)request.get(file_content); log.info(received file of name: + fpf.getFileName()); thanks,-- Collin - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 20, 2003 5:32 PM Subject: RE: Parsing multipart form data ah, that brings to mind another idea - send a snippet of your action that deals with getting the FilePart... Geoff -Original Message- From: Collin VanDyck [mailto:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: Re: Parsing multipart form data Here is my web.xml file. (It's long, so an apology in advance). I hope this helps, and I really do appreciate everyone's help in this list. I commented out overwrite-uploads and set the autosave-uploads to false, but I still get a FilePartFile instead of a FilePartArray. thanks, Collin ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameContentXML web app/display-name descriptionProvides the administration interface to the ContentXML System/description servlet servlet-nameCocoon2/servlet-name display-nameCocoon2/display-name descriptionThe main Cocoon2 servlet/description !-- In cases you're facing class loader problems you can alternatively use the following servlet-class instead of the normal one servlet-classorg.apache.cocoon.servlet.ParanoidCocoonServlet/se rvlet-clas s -- servlet-classorg.apache.cocoon.servlet.CocoonServlet/servlet-class !-- This parameter points to the main configuration file for Cocoon. Note that the path is specified in absolute notation but it will be resolved relative to the servlets webapp context path -- init-param param-nameconfigurations/param-name param-value/WEB-INF/cocoon.xconf/param-value /init-param !-- This parameter tells cocoon to set the thread's context classloader to its own classloader. If you experience strange classloader issues, try setting this parameter to true or using ParanoidCocoonServlet. -- init-param param-nameinit-classloader/param-name param-valuefalse/param-value /init-param !-- This parameter indicates the configuration file of the LogKit management -- init-param param-namelogkit-config/param-name param-value/WEB-INF/logkit.xconf/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit configuration used by the CocoonServlet. -- init-param param-nameservlet-logger/param-name param-valueaccess/param-value /init-param !-- This parameter indicates the category id of the logger from the LogKit management configuration for the Cocoon engine. This logger is used for all components described in the cocoon.xconf and sitemap.xmap file not having specified a logger with the logger=... attribute in the component configuration file. -- init-param param-namecocoon-logger/param-name param-valuecore/param-value /init-param !-- This parameter indicates the log level to use throughout startup of the system. As soon as the logkit.xconf the setting of the logkit.xconf configuration is used
