ratpack

Please see the release notes for Ratpack 1.3.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.

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.

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

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.

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.

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.

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.

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.

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

This is the last of the pre 1.0 releases. We are now landing for 1.0, with the next release being 1.0.0-RC1 in the next few weeks.

A big breaking change in this release, is the removal of the ExecControl interface. This interface provided the blocking and promise methods. Instead, it has been replaced by static methods on the Promise type and the new Blocking class. This simplifies usage by not requiring access to something that implements ExecControl.

The promise creation API has also changed slightly, with the removal of the Fufiller type in favour of Upstream.

The reading of the request body is also now asynchronous. The request.getBody() now returns a promise for the body instead of the body itself. This allows the body to be read lazily instead of eagerly, preventing the body being read into memory if it is never going to be used. Relatedly, the Context.parse() methods also now return promises.

Thanks to the contributors for this release.

We hope you are looking forward to the imminent release of Ratpack 1.0.0.

Team Ratpack.

A major focus of this release was preparing for the pending 1.0 release, primarily in terms of smoothing out some public API.

Work continued on the new session support including more convenient API for single session operations, and extra cookie configuration options.

The Chain API was given a bit of a refresh with some methods renamed and docs improved. What was previously the handler() is now called all(). The assets() has also been replaced with files().

The Pac4j support has been completely rewritten. Please see the RatpackPac4j class.

Dave Syer kindly contributed improved integration with Spring Boot. Please see the manual documentation for more info.

David Estes also released support for using the Asset Pipeline tool with Ratpack. Please see the manual documentation for more info. The ratpack.io site itself is now using the Asset Pipeline integration.

This release also includes fixes and improvements to SSL handling, request logging, compressed responses with the HTTP client, the context registry, Netty configuration and more.

Thanks also to João Cabrita, Kyle Boon, Vadi Kumar for their contributions.

This is a big release.

This release features a brand new session API, along with support for client side sessions (i.e. storing the session data in the user's cookies). The new session API makes it very easy to plug in your own persistent store of session data, via the SessionStore interface. The new SessionModule provides an in memory session store by default. This is a drastically breaking change for users of the old session API. We hope you agree that the change was worth it.

It is now easier more convenient to use externalised config, through the new ServerConfig.Builder.require() method. This method puts an object of the given type directly into the server registry making it available for later retrieval. If using Guice, the object will also be bound as an override. This makes externalising config for a ConfigurableModule very convenient.

The Pac4j integration has been rewritten from scratch, and is no longer based on Guice modules. See RatpackPac4j. This is another breaking change.

The version of Guice used has been uggraded to 4.0-final, and the version of Netty has been upgraded to the latest 4.1-beta-5.

As usual, there are a host of other bug fixes and improvements in this release as well as some improved documentation.

Happy Ratpacking.

-- Team Ratpack

The 0.9.16 release is the release of dependency upgrades! Pretty much all of the dependencies that Ratpack and its modules have are now upgraded to their latest versions. This includes Groovy, Reactive Streams, RxJava, Hystrix, Pac4j, Jackson, Handlebars......

As well as the dependency upgrades there has been some other good stuff going on too.

The format of the built-in metric names has changed and you can now "collapse" metrics into groups based on regular expressions. For example, instead of reporting metrics for book.1.update.get-requests, book.2.update.get-requests etc, you could group them to report as update.get-requests. You can see an example of how to do this in example-books. New count metrics have also been added for response status codes and metric filtering has been extended to the websocket reporter.

The session storage api is now async, which clears the path to integrating with new stores in the future such has Hazlecast and Redis. A cookie based session store has also been added as an alternative to the memory based one.

Also of note, startup and shutdown services are now asynchronous and health checks now have access to the registry.

There were also great contribution from Robert Zakrzewski (cookie session support, Javascript warning fix), Steve Anderson (documentation improvements), Tom Akehurst (Thymeleaf template fragment support), Danny Kirchmeier (Csv metric reporter improvements)

We hope you enjoy this Ratpack release.

-- Team Ratpack

Coming off the back of the monstrous 0.9.13 release, and given a short month, this release is a little lighter than the last few.
However, there's good stuff in 0.9.14.

The Guice integration has changed in this release to be better integrated with the new server registry mechanism introduced in the previous.
Objects bound with Guice are now part of the server registry.
This is mostly a transparent change to users, but will make it easier to leverage more features going forward.

As of this release Ratpack now uses Groovy 2.4.1.
This Groovy version fixes several issues with static compilation that would often surface for Ratpack applications.

There are also fixes and improvements for Metrics support, config loading, reactive streams and more.

Thanks to Robert Zakrzewski for contributing Slf4j MDC support.
This integrates the MDC concept with Ratpack's execution model.
See MDCInterceptor for details.

We hope you enjoy this release, and are looking forward to the next one as much as we are.

-- Team Ratpack.

Starting 2015 with a bang, this release is probably the most significant to date.

Before jumping into why that is, some explanation is necessary as to why we have now shipped two releases depending on 4.1.0.Beta4-SNAPSHOT.
Late during the 0.9.11 release we hit problems with the Netty 4.0.x version we were using.
While we could have worked around this problem, one way to resolve it was to upgrade to Netty 4.1.0-Beta4 which was not yet in final release.
The intention from the Netty team was to finalise this release before January 1st, before 0.9.12 was released.
We decided to upgrade and use the snapshot, banking on the final release being out before ours.
We find ourselves in the same situation for the 0.9.13 release.
If you're having issues due to this in your build, you can find some info on this issue.

The big story in this release is the complete rewrite in Ratpack's “launch” layer, and what this has enabled.
That is, how Ratpack applications are started has completely changed.
For most users of the existing Groovy entry point (i.e. what is set up by the ratpack-groovy Gradle plugin) not much will appear to have changed.
For Java users, this is a breaking change to your main class and how you started the application.
LaunchConfig, HandlerFactory and other types/concept previously used at launch are now gone.
Instead, the RatpackServer is the new entry point.
Groovy users can continue to use GroovyRatpackMain as the entry point (as setup by the ratpack-groovy Gradle plugin).

One of the fundamental changes at here is introducing a “server registry” into the definition of an application alongside the existing handler chain.
The “server registry” is the Registry that underpins the whole application.
Previously, registries were only defined inside the request handling layer.
This made it difficult to integrate with Ratpack on an application level, as the request handling layer effectively has a different lifecycle.
Now, the server registry is part of the base definition of the application and is tied to its lifecycle.
This makes it much easier to support background jobs, startup actions, shutdown actions, interceptors and much more.
Expect to see features in new releases enabled by this as well as improved API for existing features.
In this release, the new Service interface allows objects to be notified of server start and stop.

Another driver for the change was the desire to have really great support for externalised configuration.
This is something we've been working on for some time.
This release introduces the ratpack-config library.
This library makes it easy to create Java objects based on configuration data sourced from JSON, YAML and properties files as well as JVM system properties and environment variables.
While not part of ratpack-core, use of ratpack-config will be strongly recommended going forward as it makes it very easy to externalise your configuration.
The documentation on the new configuration mechanism is a little sparse right now, but we are working on it.
In the meantime, you can start with the documentation for ConfigData.
We'll be following up with blog posts and more docs over the 0.9.14 development cycle.

The reworking of the launching mechanism was also undertaken to improve Ratpack's support for changing the application without redeploy while in development.
Expect to see improvements in this area in the next release.

Thanks to Kyle Boon, Jeff Blaisdell, Glenn Saqui and Joe Kutner for contributions to this release.

We hope you enjoy this release, and are looking forward to the next one as much as we are.

-- Team Ratpack.

This release contains quite a few internal performance optimisations in terms of increased throughput and reduced memory consumption. Work is continuing on the documentation and supporting materials such as getting started guides.

The big new feature added in this release is the new RxJava module, that provides a reactive alternative to Ratpack's Background API, namely RxBackground (see link for usage examples). This makes dealing with non trivial blocking data flows trivially easy and avoids nested callbacks.

There are breaking API changes in this release, as there is likely to be in each release until 1.0 final.

February is a short month, and members of the Ratpack team are dealing with life changing events so things have been a little quiet on the Ratpack front. However, 0.9.2 still has some great improvements.

Thanks to David M. Carr for some great contributions in this release. It's now much easier to add custom dialects when using the Ratpack Thymeleaf integration. Thanks to David, Ratpack's Guice support now also includes multibinding support.

Work is continuing on the metrics support, with a pre canned handler for displaying a metrics dashboard ready to go. See Rus's tweet for an example.

This release also sees the addition of the ratpack-hikari library for integrating the super efficient JDBC connection pooling library HikariCP. This is being used for Ratpack's, under development, entry into the Techempower benchmarks. Thanks dimzava for some great contributions to our entry. We hope to be ready for round 10 so we can see how Ratpack's performance stacks up against other frameworks. Our initial data is looking very good.

March has been a big month.

Our newest committer, David Carr has already made many contributions including a new ratpack-pac4j module which brings many authentication and authorization options and is the successor to the popular Scribe library.
This module allows you to effortlessly delegate authentication to OpenID and OAuth providers like Google for example.

Russell Hart has done some great work on the support for metric collection and health checks, for which there is now some introductory documentation.

Some significant work has gone into the manual for this release, including new chapters on "Deploying to Heroku" and "Building with Gradle".
Work continues on the documentation and we've (hopefully) made it easier for you to contribute to it by fleshing out the documentation on the documentation, which explains how it all works and what it's all about.

Another significant piece of work performed this month was the creation of the initial version of the project's performance testing suite.
This suite will effectively micro benchmark the in-development version of Ratpack against the previous release to both highlight performance regressions and quantify optimizations.
Hopefully by the next release, we'll have these tests running nightly with the results published publicly.

A special mention to Craig Burke as the sole contributor for 0.9.3 with some improvements to unmarshalling JSON requests into objects with the ratpack-jackson module (which is unfortunately severely under documented).

There have been a mix of other improvements and new features added, the details of which are below.

We hope you enjoy Ratpack 0.9.3.

The 0.9.4 release brings many internal, and some external, changes.

The majority of the work has gone into restructuring and formalising the execution control mechanisms. This opens the door for non request handling work to share the same asynchronous execution control mechanisms.

This release also saw the introduction of core support for a HTTP client. The HTTP client shares the same Netty event loop (i.e. thread pool) as the HTTP server, which yields better throughput and efficiency. The docs on the HTTP client are minimal at this stage, but you can see example usage in the example-books sample project.

0.9.4 also contains some internal optimizations that make all Ratpack apps a little faster. We hope you enjoy it.