Carsten Ziegeler wrote:
Patrick Refondini schrieb:
Using cocoon-samples.war I try to set up the max upload size.
Looking at the source I thought the right place to do it is in the o.a.c.servlet.multipart.MultipartFilter thus in web.xml :

   <filter>
     <filter-name>CocoonMultipartFilter</filter-name>
     <display-name>Cocoon multipart filter</display-name>
     <description>Multipart MIME handling filter for Cocoon</description>
<filter-class>org.apache.cocoon.servlet.multipart.MultipartFilter</filter-class>

Added this:
 >>>>
     <init-param>
       <param-name>maxUploadSize</param-name>
       <!-- Expect to set up 200M -->
       <param-value>200000000</param-value>
       <description>Set the size limit for uploaded files.</description>
     </init-param>
<<<<
   </filter>

It does not work. Any hint welcome.

You have to set the configuration filter in the settings for Cocoon,
which means you have to define them via properties.

Have a look at the core.properties file in the cocoon-core module.
I found core.properties in:
core/cocoon-core/src/main/resources/META-INF/cocoon/properties
Got the upload Graal as a bunch of org.apache.cocoon.uploads properties :)

Just put a properties file with the appropriate configuration into
WEB-INF/cocoon/properties. This should work.
I will test it.


I use cocoon-samples.war built from latest cocoon_trunk deployed in Tomcat 5.5.20 container. I have been able to change the max upload size for the same webapp using maven jetty plugin in the command line like:
mvn -Dorg.apache.cocoon.uploads.maxsize=200000000 jetty:run
Yes, you can override the properties on startup by specifying system
properties.

In general I think we should rather use filter parameters here and not
the Cocoon settings object.

WDAT?
I guess the idea of "the configuration filter in the settings for Cocoon" is:

1. To avoid dealing with specifics such as a given servlet filter object ( e.g. MultipartFilter ) configuration but use a generic point of entry for Cocoon configurations ?

2. To hide to the user one config file possibly configures several "Cocoon settings objects" ?

3. In addition it might ease configuration backward compatibility in case of implementation change ?

So if I got it right, which I am not certain, the term "filter" appearing a bit everywhere :) I think using the proposed properties files mechanism should benefit to Cocoon users (simplicity).

Thanks for the input, I'll post the test feedback,

Patrick



Carsten



Reply via email to