v2.6

Version: 2.6.20180430102904

Documentation (pdf)

Experimental support for reactive/async programming

The new module `crnk-reactive` integrates projectreactor.io/ into Crnk to support reactive programming. A basic in-memory example looks like:

 {

	private Map resources = new HashMap<>();

	public InMemoryReactiveResourceRepository() {
		super(Task.class);
	}

	@Override
	public Mono> findAll(QuerySpec querySpec) {
		return Mono.fromCallable(() -> querySpec.apply(resources.values()));
	}

	@Override
	public Mono create(Task entity) {
		return save(entity);
	}

	@Override
	public Mono save(Task entity) {
		resources.put(entity.getId(), entity);
		return Mono.just(entity);
	}

	@Override
	public Mono delete(Long id) {
		return Mono.fromCallable(() -> resources.remove(id) != null);
	}
}
]]>

Main benefits over the traditional API are:

• Individual requests no longer block threads. Instead multiple requests share can share a pool of worker threads. Allows to implement highly concurrent applications.
• Requests get parallelized automatically. This may happen both within the repository implementation and the crnk engine. For example, inclusions can be requests in parallel. Or a repository may call multiple services in parallel and return the aggregated result.

Currently this is considered experimental. For more information and limitations have a look at the documentation. In particular the lack of an asynchronous JDBC/JPA implementation is a bit of a roadblock for some application.

AsyncCrnkServlet

There is a new AsyncCrnkServlet that complements crnk-reactive. In contrast to the CrnkServlet, requests get processed asynchronous and share a set of worker threads.

Vert.x

With support for reactive programming comes experimental support for Vert.x as well.

> completionHandler = event -> waitSubject.onSuccess(event.result());

vehicle = new CrnkVerticle(port);
vertx = Vertx.vertx(options);
vertx.deployVerticle(vehicle, completionHandler);
]]>

Updates to www.crnk.io

The web page has been been refreshed a bit. Most notably the update of the web page has been integrated into the release process and documentation gets published automatically:

• There is a dedicated release page for each minor version. It holds information about the latest release in that minor version. Release versions continue to follow the major.minor.gitTimestamp convention.
• The latest release page points to the current master version including the most current documentation.
• The stable release page points towards the most recent release page.

Dedicated security chapter

The documentation hosts a new chapter dedicated to security. It aggregates the various security-related topics in one chapter.

@JsonProperty support for QuerySpec

The @JsonProperty annotation allows to rename fields in the JSON response. Since this release the same name mapping is applied to filter, sort, field set and inclusion parameters in QuerySpec. DefaultQuerySpecUrlMapper.setMapJsonNames allows to disable the behavior.

Refinements to custom PagingBehavior registration

Registering a custom PagingBehavior implementation makes it the global default in an application. It is no longer necessary to explicitly refer to the new implementation in @JsonApiResource.pagingBehavior. @JsonApiResource.pagingBehavior can continue to be used if multiple PagingBehavior implementations are used for different resources.

URL Mapping of QuerySpec

The functionality of QuerySpecSerializer and QuerySpecDeserializer has been merged into a new interface QuerySpecUrlMapper. The functionality of the two have been closely related and changes usually needed to be applied to both. The new interface simplifies more consistent URL handling and eases customizing that behavior.

Improved exception handling

• Invalid request parameters now return a 400 BAD_REQUEST_ERROR with a proper source parameter declaration to simplify tracking down the illegal parameter.
• If JSON API repositories are invoked with an illegal method, a 405 METHOD_NOT_ALLOWED is returned.

Server information

With CrnkBoot.putServerInfo(...) information about the server can be made available to clients. For example:

{
	"data": [...]
	"jsonapi": {
		"vendor":"crnk"
	}
}

Streamlined project naming

Setup related projects newly share a crnk-setup prefix:

Previous name	New name
crnk-cdi	crnk-setup-cdi
crnk-guice	crnk-setup-guice
crnk-rs	crnk-setup-rs
crnk-servlet	crnk-setup-servlet
crnk-spring	crnk-setup-spring, crnk-setup-spring-boot1 and crnk-setup-spring-boot2

The previous projects still exists and point have the new projects as dependency. At some point in the future those projects will be removed.

The SpringBoot-related functionality has further been moved into dedicated crnk-setup-spring-boot projects, one for version 1.x and one for version 2.x.

Improved Spring Boot 2 support

crnk-setup-spring-boot2 is a new project dedicated to Spring Boot 2. This includes:

• Cleanup of package naming.
• New interface CrnkBootConfigurer to customize CrnkBoot without having to replace the auto configuration.
• Support for Typescript generation.

crnk-bom

crnk-bom is a Maven BOM managing the versions of all crnk artifacts.

Fixes

• QuerySpec.duplicate also duplicates nested data structures like paging specs and filters.
• Guava dependencies have been removed from crnk-core.
• totalResourceCount is omitted from the response if null.

Move to Bintray

OSS hosting on Sonatype has proven to be rather unreliable. The project has now moved to JFrog Bintray. The repository is available at: https://bintray.com/crnk-project/maven.