v1.3.0-rc-1

Please see the release notes for Ratpack 1.3.0.

v1.2.0

After taking some time off after the 1.0 and subsequent 1.1 releases, we are back with 1.2.
There's a lot of new stuff.

It is now possible to disable the execution timing feature of the Dropwizard Metrics support.

The version of Spring Boot used by default by the Spring Boot integration has been updated to 1.3.0,
along with documentation refinements and improvements from the Spring Boot team.

A new utility has been added for simple pub/sub with promises, named Promised.

A bug that prevented Groovy script entry points being able to be reloaded in some scenarios was fixed.

The PublicAddress type has changed to no longer require a Context.
The existing methods that did require a context have been deprecated.
It is now also possible to obtain an implementation that infers the public address based on the request.

Handling of 100-Continue requests has been improved.
If a request contains Expect: 100-Continue, a 100 Continue response is issued automatically when the request body is actually read.
Ratpack will not implicitly issue a 417 Expectation Failed response to reject the request.
It will simply send the response that is specified in the handling code as per normal.

The underlying Redis client used by the RedisSessionModule has been upgraded to the latest.

A brand new “imposition” mechanism has been added that facilitates augmenting applications under test, from outside of the application, at test time.
This enables the often requested feature of being able to augment Guice bindings at test time, via the BindingsImposition.
This is a very powerful feature that makes Ratpack applications even easier to test.

The Pac4j integration has been updated to build on Pac4j 1.8, and use some new features.
Principally, there is now a handler for authorizing as well as authenticating.

It is now also possible to read the incoming request body as a stream, via the Request.getBodyStream() method.
This method exposes the bytes of the request body as a Reactive Streams Publisher.
One of the key features of the Reactive Streams protocol is that it allows back pressure on the stream.
In this scenario, this means that the consumer can control the rate at which the body is read into memory which avoids exhaustion.
This facilitates full asynchronous streaming with flow control.
Subsequent versions of Ratpack will include utilities for writing such streams to common destinations such as blocking OutputStreams.

There are many other documentation improvements and squashed bugs in this release, with many coming via contribution.
Thanks to everyone who contributed to this release.

You can expect minor releases roughly every two months into the future.

We hope you enjoy Ratpack 1.2.0.

Upgrading from 1.1.x

Pac4j changes

The Pac4j integration has been updated to build on Pac4j 1.8 where it was previously 1.7.
There are some breaking changes to pac4j across this version change.
There have also been some binary incompatible changes made to the RatpackPac4j class in order to accommodate, but the changes are source compatible.

Changes to MainClassApplicationUnderTest.createOverrides()

This method has been removed, which is a breaking change to subclasses.
The user registry override mechanism that this method facilitated has been superseded by the new, more general, impositions mechanism.

If you were previously using this method, you should override the new addImpositions() method instead,
and use a UserRegistryImposition.

Note that it is now possible to impose into the Guice registry directly, via BindingsImposition.

v1.2.0-rc-2

This release fixes a single issue identified with the first release candidate that caused tests using the test HTTP client to be slower than they should have been.

Please consult the 1.0.0-rc-1 release announcement for more detail on what's new 1.0.0.

v1.2.0-RC-1

Finally… the Ratpack 1.0.0 release candidate.
It's been a two and half year journey, but we are finally here.
We plan to release 1.0.0 final roughly two weeks after the RC release, depending on the feedback.

First off, thank you to everyone who has supported the project in any way over the recent years.
Ratpack is a volunteer effort; no one gets paid to work on it and no one gets paid by people using it.
We've received many pull requests, bug reports, feature suggestions and praise which provide the motivation to keep going.
You can see the list of people who have contributed code to the project in the credits section of the manual.

There are quite a few changes in this release from 0.9.19.

The development time reloading strategy has changed from using runtime class patching (using SpringLoaded), to using Gradle's Continuous Build feature.
This is a far more reliable strategy and greatly simplifies IDE integration for Ratpack apps (i.e. no special integration is needed).
Try it out by running ./gradlew run --continuous on your project, after upgrading to Gradle 2.6 (Ratpack now requires this version).
The Ratpack runtime has no knowledge of Gradle.
It is entirely theoretically possible to integrate Ratpack with the equivalent feature in another build tool should it exist.

The request body can now only be read once during a request.
Its byte buffer can now also be eagerly released to free the memory if desired.
This change is in preparation for the coming feature in Ratpack 1.1.0 of deferring the reading of the body over the wire until it is requested.

The ratpack-jackson-guice library has been removed.
The functionality that it provided is now part of ratpack-core.
That is, renderers and parsers for working with the types of Jackson are now available automatically.
The ratpack-core library already depended on Jackson for the config mechanism.
Besides the removal of the library and the JacksonModule class, the main change you will need to make is how you customise Jackson.
See “Configuring Jackson”.

The Parser API has also simplified.
For parse operations with no options, the parse objects now returns no options instead of a NullParseOpts marker.
Also, parsers are no longer restricted to a content type.
An implementation can now potentially parse multiple content types.

RemoteControl now accepts UnserializableResultStrategy.
The default value is io.remotecontrol.client.UnserializableResultStrategy.throw.
It is now also possible to specify uses closures (i.e. external closures that are used by the command closure) as well.

ReceivedResponse#send and StreamedResponse#send have been changed to ReceivedResponse#forwardTo and StreamedResponse#forwardTo

Redis session storage is now supported in the ratpack-session-redis library. See "RedisSessionModule" for details.

The ratpack-codahale-metrics module has been renamed to ratpack-dropwizard-metrics.
The configuration classes associated with this module are no longer inner classes of the module, you will need to use ratpack.dropwizard.metrics.DropwizardMetricsConfig

The 1.0.0 release doesn't mean that Ratpack is “done”.
There are still things to add, and no doubt bugs to squash, but it's both a symbolic and practical milestone.
It's symbolic in that we are asserting that it's at a certain level of maturity and is applicable to a good number of projects.
It's practical in that we are now striving for API compatibility (i.e. no more breaking changes).
What this means is that you should be able to upgrade your app on the 1.x line in order to incorporate new features and fixes without your existing code breaking.
We will be taking this very seriously, but of course we are mere humans and uncaught mistakes may be made.

1.0.x releases will occur as frequently as needed in response to bug fixes and internal improvements.
After the release of 1.0.0, improving the documentation will be a key focus.

Please try the release candidate on your projects promptly and let us know of any problems so they can be fixed before the 1.0.0 final release.

We hope you are as excited as we are about Ratpack 1.0.0.

Team Ratpack

v1.1.1

This release fixes a bug that was introduced in 1.1.0 that could cause requests to hang in development mode.

Please see the release notes for 1.1.0 for the full information about the 1.1.x line.

v1.1.0

The big feature of Ratpack 1.1 is the added support for deferring the read of request bodies.
In 1.0 and prior, the request body was read eagerly and held in memory before control was passed to the application code.
As of 1.1, this now happens on demand when the promise returned by Response.getBody() is subscribed to.
There are also now variants of this method that allow the maximum size to be specified, along with actions to take should the body be too large.
This change opens up many options for dealing with request bodies, such as throttling and dynamic maximum allowed sizes based on other request attributes (i.e. authorization).
Ratpack 1.2 will add support for streaming the request body in, avoiding the need to hold it all in memory at once.

This release also has many other improvements and new features.

Support for dealing with OPTIONS requests with custom responses is now supported thanks to a contribution from Guillaume Laforge.

Hot reloading within the Groovy Console now works, making it a convenient place to prototype ideas for Ratpack apps written in Groovy.

The new MDCInterceptor.withInit() method makes it easier to initialize the MDC context for an execution.

It is now possible to specify a connection timeout when using the HttpClient thanks to a contribution from James Lee.

The built in JSON parsing (backed by Jackson) now will attempt to parse any content type that ends with +json, in addition to application/json.
This is useful when dealing with vendor types that are actually JSON.

When using the Pac4j integration, it is now possible to determine the authentication clients to use based on the request details
by using the new RatpackPac4j.authenticator() method that takes a function to determine the clients.

The new onError() promise methods make dealing with certain kinds of errors occurring.

It is now easy to use the application arguments as a source of config, via the new args(String[]) method on ServerConfigBuilder.
Relatedly, when using a Groovy script as the application entry point (i.e. when using the ratpack-groovy Gradle plugin), the application args are now available as the args script variable.

There are also significant performance optimisations in this release, particularly around memory consumption.

We hope you enjoy Ratpack 1.1.0.

Team Ratpack.

v1.0.0

After two and half years, we now have a 1.0 release.
Ratpack has now graduated to API stability.

Please consult the release notes for the first release candidate for changes since 0.9.19.

On behalf of the team, I'd like to take the opportunity to thank everyone who contributed to Ratpack, be it by way of code or comment.
The names of all who have contributed code can be found in our credits section.

While this is a significant milestone, it's just a milestone.
Ratpack will continue to evolve and improve.
We hope that the promise of API stability that the 1.0.0 release signifies will make it easier for more people to make the case for Ratpack which will inevitably lead to a better Ratpack.

We hope you enjoy Ratpack 1.0.0.

Team Ratpack.

v1.0.0-rc-3

This release has one change from 1.0.0-rc-2; it adds compatibility with Gradle 2.7.

Please consult the release notes for 1.0.0-rc-1 for the full list of changes in the 1.0.0. release.

v1.0.0-rc-2

This release fixes a single issue identified with the first release candidate that caused tests using the test HTTP client to be slower than they should have been.

Please consult the 1.0.0-rc-1 release announcement for more detail on what's new 1.0.0.

v1.0.0-rc-1

Finally… the Ratpack 1.0.0 release candidate.
It's been a two and half year journey, but we are finally here.
We plan to release 1.0.0 final roughly two weeks after the RC release, depending on the feedback.

First off, thank you to everyone who has supported the project in any way over the recent years.
Ratpack is a volunteer effort; no one gets paid to work on it and no one gets paid by people using it.
We've received many pull requests, bug reports, feature suggestions and praise which provide the motivation to keep going.
You can see the list of people who have contributed code to the project in the credits section of the manual.

There are quite a few changes in this release from 0.9.19.

The development time reloading strategy has changed from using runtime class patching (using SpringLoaded), to using Gradle's Continuous Build feature.
This is a far more reliable strategy and greatly simplifies IDE integration for Ratpack apps (i.e. no special integration is needed).
Try it out by running ./gradlew run --continuous on your project, after upgrading to Gradle 2.6 (Ratpack now requires this version).
The Ratpack runtime has no knowledge of Gradle.
It is entirely theoretically possible to integrate Ratpack with the equivalent feature in another build tool should it exist.

The request body can now only be read once during a request.
Its byte buffer can now also be eagerly released to free the memory if desired.
This change is in preparation for the coming feature in Ratpack 1.1.0 of deferring the reading of the body over the wire until it is requested.

The ratpack-jackson-guice library has been removed.
The functionality that it provided is now part of ratpack-core.
That is, renderers and parsers for working with the types of Jackson are now available automatically.
The ratpack-core library already depended on Jackson for the config mechanism.
Besides the removal of the library and the JacksonModule class, the main change you will need to make is how you customise Jackson.
See “Configuring Jackson”.

The Parser API has also simplified.
For parse operations with no options, the parse objects now returns no options instead of a NullParseOpts marker.
Also, parsers are no longer restricted to a content type.
An implementation can now potentially parse multiple content types.

RemoteControl now accepts UnserializableResultStrategy.
The default value is io.remotecontrol.client.UnserializableResultStrategy.throw.
It is now also possible to specify uses closures (i.e. external closures that are used by the command closure) as well.

ReceivedResponse#send and StreamedResponse#send have been changed to ReceivedResponse#forwardTo and StreamedResponse#forwardTo

Redis session storage is now supported in the ratpack-session-redis library. See "RedisSessionModule" for details.

The ratpack-codahale-metrics module has been renamed to ratpack-dropwizard-metrics.
The configuration classes associated with this module are no longer inner classes of the module, you will need to use ratpack.dropwizard.metrics.DropwizardMetricsConfig

The 1.0.0 release doesn't mean that Ratpack is “done”.
There are still things to add, and no doubt bugs to squash, but it's both a symbolic and practical milestone.
It's symbolic in that we are asserting that it's at a certain level of maturity and is applicable to a good number of projects.
It's practical in that we are now striving for API compatibility (i.e. no more breaking changes).
What this means is that you should be able to upgrade your app on the 1.x line in order to incorporate new features and fixes without your existing code breaking.
We will be taking this very seriously, but of course we are mere humans and uncaught mistakes may be made.

1.0.x releases will occur as frequently as needed in response to bug fixes and internal improvements.
After the release of 1.0.0, improving the documentation will be a key focus.

Please try the release candidate on your projects promptly and let us know of any problems so they can be fixed before the 1.0.0 final release.

We hope you are as excited as we are about Ratpack 1.0.0.

Team Ratpack