[Announce] Wicket Stuff Core 1.5-RC4.2 Released

[Michael O'Cleirigh]

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>
<groupId>org.wicketstuff</groupId>
<artifactId>wicket-security-swarm</artifactId>
<version>1.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 reverted on the
soon to be made 1.5-RC4 wicketstuff branch!
       [minis] New StringValidator variants that add maxlength attribute
to the html tag. This can be deprecated/dropped as soon as
https://issues.apache.org/jira/browse/WICKET-1310 gets merged into
Apache Wicket.

Emond Papegaaij (11 commits):
       moved wicket-security into wicketstuff-core
       Merge branch 'wisec'
       Ported wicket security to wicket 1.5
       Merge branch 'master' of github.com:wicketstuff/core
       final artifact ids
       fixed testcase that did not work with redirect to original dest
       Renamed org.apache.wicket.security to org.wicketstuff.security
       Merge branch 'master' of github.com:wicketstuff/core

Pedro Santos (10 commits):
       - development of TableComponentAsXlsHandler to export Wicket
table     components to Xls files     - added a link exemplifying the
new handler in inmethod-grid and     minis example project
       reverting web.xml configuration change
       Merge remote branch 'choose_remote_name/master'
       removing POI dependence
       moving test case from inmethod project
       code cleanup
       - respecting row and column span     - refactoring parser code to
be better tested     - test cases ( involved include test dependencies
in pom.xml)
       - fix http://github.com/wicketstuff/core/issues/26     -
refactoring internal code
       Fixing colsToSpan formula
       reverting PoiTestUtil

Nick Wiedenbrueck (9 commits):
       [console] refactoring bindings in ClojureEngine
       [console] refactoring packaged script templates
       [console] added packaged clojure scripts
       [console] fixing tests
       Merge branch 'master' into console
       [console] remove wicket dependencies from templates
       [console] replaced tabs with spaces
       [console] removed onInitialize for extension
       [console] merging master

Sven Meier (8 commits):
       migrated to Wicket 1.5
       now depending on jslibraries, deprecated
       log warning for installation of custom javascript
       added test
       migrated modules
       Merge branch 'master' of https://github.com/wicketstuff/core
       added another assert
       javadoc

Inaiat Henrique (5 commits):
       [mootools-meiomask] more examples and unit tests
       [mootools-meiomask] more examples and unit tests
       [mootools-meiomask] more examples and unit tests
       [mootools-meiomask] delete obsolete class
       [mootools-meiomask] unit tests and suport to all meiomask types

Michael O'Cleirigh (5 commits):
       replace changelog/release message with git commit comment based
approach
       Merge pull request #27 from eikek/topic/wicket-bundle
       commit wicketstuff-core 1.5-RC4.2 release pom's
       Revert "Following the IHeaderContributor related upstream change
so the code compiles again.
       [core] include jboss repository for hibernate in release profile

seb (4 commits):
       Code cleanup (license header, serialVersionUID, ...
       wicket-shiro: (license header, serialVersionUID), wicket-minis:
integrated wicket-miscs
       shiro, minis: code cleanup
       minis: code cleanup

martin-g (2 commits):
       Re-enable misc/ subproject.
       Re-enable jquery subproject.

Eike Kettner (1 commit):
       added wicket-bundle project to use wicket in osgi env

(This listing was generated using: git shortlog -n
wicketstuff-core-1.5-RC3..wicketstuff-core-1.5-RC4.2 and excludes
commits related to the wicket-security merge).

I will plan to do the next release within one month of today but if you
commit code and/or need a release cut sooner please either contact me
directly or file a ticket.

Regards,

Mike


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Phil Franken]

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: [hidden email]
For additional commands, e-mail: [hidden email]

[Pedro Santos]

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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



--
Pedro Henrique Oliveira dos Santos

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Phil Franken]

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 Franken<[hidden email]>  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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Pedro Santos]

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 <[hidden email]> 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 Franken<[hidden email]>
>>  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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Pedro Henrique Oliveira dos Santos

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Phil Franken]

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 Franken<[hidden email]>  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 Franken<[hidden email]>
>>>   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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Pedro Santos]

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 <[hidden email]> 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 Franken<[hidden email]>
>>  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 Franken<[hidden email]>
>>>>  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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Pedro Henrique Oliveira dos Santos

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]