Re: [Announce] Wicket Stuff Core 1.5-RC4.2 Released
Are there any plans to include a fix for this in 1.14.18? https://issues.apache.org/jira/browse/WICKET-3594 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [Announce] Wicket Stuff Core 1.5-RC4.2 Released
Hi Phil, I'm about to upload a quickstart to this ticket proving it is not a Wicket related problem. The container is always reading the entire input stream regardless of the application doing it or not. I talked about in IRC and Igor suggested me to close the stream if it exceed the max limit, but by doing so the client gets no response and browser shows a page saying that the connection to server are lost. On Thu, May 12, 2011 at 3:39 AM, Phil Franken phil.fran...@gmail.com wrote: Are there any plans to include a fix for this in 1.14.18? https://issues.apache.org/jira/browse/WICKET-3594 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pedro Henrique Oliveira dos Santos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [Announce] Wicket Stuff Core 1.5-RC4.2 Released
Thanks for the update Pedro. I concur with your assesment based on what I've seen, but this makes me worry. Does this mean if I set a file size limit of 1MB and someone uploads a 2GB file the container will read the entire 2GB? Not good, with or without progress bar. Anyone suggestions on how to handle this? On 5/12/2011 7:47 AM, Pedro Santos wrote: Hi Phil, I'm about to upload a quickstart to this ticket proving it is not a Wicket related problem. The container is always reading the entire input stream regardless of the application doing it or not. I talked about in IRC and Igor suggested me to close the stream if it exceed the max limit, but by doing so the client gets no response and browser shows a page saying that the connection to server are lost. On Thu, May 12, 2011 at 3:39 AM, Phil Frankenphil.fran...@gmail.com wrote: Are there any plans to include a fix for this in 1.14.18? https://issues.apache.org/jira/browse/WICKET-3594 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [Announce] Wicket Stuff Core 1.5-RC4.2 Released
You can setup a firewall to prevent DOS attacks, I'm not sure if Wicket needs to read the input stream regardless of its HTTP header specifying that the upload exceed the limit just to close the stream. On Thu, May 12, 2011 at 1:52 PM, Phil Franken phil.fran...@gmail.com wrote: Thanks for the update Pedro. I concur with your assesment based on what I've seen, but this makes me worry. Does this mean if I set a file size limit of 1MB and someone uploads a 2GB file the container will read the entire 2GB? Not good, with or without progress bar. Anyone suggestions on how to handle this? On 5/12/2011 7:47 AM, Pedro Santos wrote: Hi Phil, I'm about to upload a quickstart to this ticket proving it is not a Wicket related problem. The container is always reading the entire input stream regardless of the application doing it or not. I talked about in IRC and Igor suggested me to close the stream if it exceed the max limit, but by doing so the client gets no response and browser shows a page saying that the connection to server are lost. On Thu, May 12, 2011 at 3:39 AM, Phil Frankenphil.fran...@gmail.com wrote: Are there any plans to include a fix for this in 1.14.18? https://issues.apache.org/jira/browse/WICKET-3594 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pedro Henrique Oliveira dos Santos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [Announce] Wicket Stuff Core 1.5-RC4.2 Released
Firewall not really an option (no budget). Ok so instead of closing the stream can you at least make sure the progress bar is invisible and let the container do its thing? I'm using Tomcat do you know of any way to set a max file size in Tomcat? On 5/12/2011 1:02 PM, Pedro Santos wrote: You can setup a firewall to prevent DOS attacks, I'm not sure if Wicket needs to read the input stream regardless of its HTTP header specifying that the upload exceed the limit just to close the stream. On Thu, May 12, 2011 at 1:52 PM, Phil Frankenphil.fran...@gmail.com wrote: Thanks for the update Pedro. I concur with your assesment based on what I've seen, but this makes me worry. Does this mean if I set a file size limit of 1MB and someone uploads a 2GB file the container will read the entire 2GB? Not good, with or without progress bar. Anyone suggestions on how to handle this? On 5/12/2011 7:47 AM, Pedro Santos wrote: Hi Phil, I'm about to upload a quickstart to this ticket proving it is not a Wicket related problem. The container is always reading the entire input stream regardless of the application doing it or not. I talked about in IRC and Igor suggested me to close the stream if it exceed the max limit, but by doing so the client gets no response and browser shows a page saying that the connection to server are lost. On Thu, May 12, 2011 at 3:39 AM, Phil Frankenphil.fran...@gmail.com wrote: Are there any plans to include a fix for this in 1.14.18? https://issues.apache.org/jira/browse/WICKET-3594 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [Announce] Wicket Stuff Core 1.5-RC4.2 Released
Hi Phil, I replied in the ticket. Just realize it is not the right thread to talk about. On Thu, May 12, 2011 at 2:10 PM, Phil Franken phil.fran...@gmail.com wrote: Firewall not really an option (no budget). Ok so instead of closing the stream can you at least make sure the progress bar is invisible and let the container do its thing? I'm using Tomcat do you know of any way to set a max file size in Tomcat? On 5/12/2011 1:02 PM, Pedro Santos wrote: You can setup a firewall to prevent DOS attacks, I'm not sure if Wicket needs to read the input stream regardless of its HTTP header specifying that the upload exceed the limit just to close the stream. On Thu, May 12, 2011 at 1:52 PM, Phil Frankenphil.fran...@gmail.com wrote: Thanks for the update Pedro. I concur with your assesment based on what I've seen, but this makes me worry. Does this mean if I set a file size limit of 1MB and someone uploads a 2GB file the container will read the entire 2GB? Not good, with or without progress bar. Anyone suggestions on how to handle this? On 5/12/2011 7:47 AM, Pedro Santos wrote: Hi Phil, I'm about to upload a quickstart to this ticket proving it is not a Wicket related problem. The container is always reading the entire input stream regardless of the application doing it or not. I talked about in IRC and Igor suggested me to close the stream if it exceed the max limit, but by doing so the client gets no response and browser shows a page saying that the connection to server are lost. On Thu, May 12, 2011 at 3:39 AM, Phil Frankenphil.fran...@gmail.com wrote: Are there any plans to include a fix for this in 1.14.18? https://issues.apache.org/jira/browse/WICKET-3594 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pedro Henrique Oliveira dos Santos - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
[Announce] Wicket Stuff Core 1.5-RC4.2 Released
Hello, Following the release this morning of wicket 1.5-RC4.2 I have built and deployed a matching wicketstuff-core 1.5-RC4.2 release. The artifacts have been promoted and synced into the maven central repository. They can be retrieved like this: dependency groupIdorg.wicketstuff/groupId artifactIdwicket-security-swarm/artifactId version1.5-RC4.2/version /dependency The release tag is here: https://github.com/wicketstuff/core/tree/wicketstuff-core-1.5-RC4.2 Development on the next release takes place on the master branch here: https://github.com/wicketstuff/core Issues can be reported here: https://github.com/wicketstuff/core/issues The Project Wiki is available here: https://github.com/wicketstuff/core/wiki New modules included in this release: wicket-security wicket-bundle wicket-poi jslibraries Changelog between wicketstuff-core-1.5-RC3 and this release: akiraly (56 commits): [html5] Renaming Behaviour to Behavior for consistency. Replacing deprecated calls. Removing some unnecessary @SuppressWarnings(unchecked) annotations. [html5] Minor modification in doc and js. [console-templates] Attempt to fix a test that fails on wicketstuff.org's jenkins CI. [console-templates] Fixing a test that fails on wicketstuff.org's jenkins CI. [springreference-examples] Cosmetic changes. [misc] pom and code cleanup. [jquery] pom and code cleanup. [phonebook] fix and reenable tests. [servlet3] Bump jetty to 8.0.0.M2. [minis] Adding a new feedback panel component and an image dimension providing behavior. [console] Correcting a sneaky typo. [jquery] Correcting pom dependency. Misc was merged into minis. [phonebook] Javadoc correction. [wicket-security] Some pom cleanup. Correcting hsqldb dependency so jdk-1.5 projects depend on the JDBC3 variant instead of the JDBC4 implementation which is for jdk-1.6. [springreference] Replacing commons-logging transitive dependency with jcl-over-slf4j. [meiomask] Fixing 2 tests so they do not depend on a specific default timezone value. [html5] Adding tests for fileapi behaviors. [html5] Fixing an NPE in one of the examples. Formatting + code cleanup on java source files using wicket rules. [wicket-security-parent] Deleting Eclipse specific .settings from repository to be consistent with other projects. [core] Bumping version to latest stable for some dependencies (minor version changes). Sorting modules in jdk-1.5 pom. Fixing a maven warning in calendarviews-parent/pom.xml. Adding some eclipse specific settings files. They can be imported into an Eclipse workspace. Cleanups in pom.xml-s. Dependency versions inherited from core pom. Some plugin configs moved to core pom. Modified a few web.xml-s to use servlet 2.5 header. Fixing incorrect/missing logging configurations used by unit tests. [wicket-poi] #24 Moving poi based components from minis to a new module. Fixing Eclipse warnings. Mostly Java related. Eclipse warning cleanups. Replacing CompressedResourceReference with PackageResourceReference as the latter was removed from Apache Wicket. [mbeanview] Fixing some generics related warnings [inmethod-grid] Replacing CompressedResourceReference with PackageResourceReference as the latter was removed from Apache Wicket. [inmethod-grid] Added generics. It is a big change any code review is welcomed. [core] Moving javadoc bundle generation to profile so it is only performed during releases. This should speed up (non-release) builds. Eclipse warning cleanups. [minis] Making ImageDimensionProviders a bit more robust. [minis] javadoc fix. [wicket-poi] Fixing a test failing on jenkins CI. [wicket-poi] Renaming test as it is testing now a different page. Bumping jetty to latest stable version (7.4.0). [inmethod-grid] Adding javadoc about the recently added generic types. Also some minor cosmetic code change. [inmethod-grid] javadoc typo fix. Ehcache updated from 2.4.1 to 2.4.2. Fixing some findbugs warnings. [console-templates] Adding slf4j binding for tests. Adding spring annotation driven injection support for wicket. This means that with AbstractSpringDependencies it is possible to use spring annotations (for example @Autowired, @Qualifier) for injection in wicket apps. Following the IHeaderContributor related upstream change so the code compiles again. [springreference] No need to call init() in clone(). [poi] Fixing a failing test. [bundle] Moving plugin version info to core. Updating hibernate and groovy dependencies. [poi] Cosmetic change in transitive test related dependencies. Following the IHeaderContributor related upstream change so the code compiles again. !Note! This commit might need to be
