17. Feburary 20182.5.20180215232038 is available with further incremental improvements to the relationship handling.
- New RelationshipMatcher class returned by RelationshipRepositoryV2.getMatcher(). It allows for much more flexible control of which relationship repository services which relationships. Before, a relationship repository was limited to a source and target resource class. Now it accepts any combination of source class, source resource type, source field, target class, target resource type and target field,
- ForwardingRelationshipRepository unifies the functionality of RelationshipRepositoryBase and ImplicitOwnerBasedRelationshipRepository. It is backed by a ForwardingGetStrategy and ForwardingSetStrategy that specify how requests are forwarded to the two adjacent resource repositories to avoid having to implement a custom relationship repository. The repository is be enabled for use with the @JsonApiRelation.repositoryBehavior annotation property.
- @JsonApiRelation.repositoryBehavior supports a new value FORWARD_OPPOSITE. To forward all calls to the opposite repository.
- IMPLICIT_FROM_OWNER and IMPLICIT_GET_OPPOSITE_MODIFY_OWNER have been deprecated in favor of FORWARD_OWNER and FORWARD_GET_OPPOSITE_SET_OWNER as @JsonApiRelation.repositoryBehavior values.
- RegistryEntry.getResourceRepositoryFacade(...) provides an API to access resource repository programmatically from a ResourceRegistry. The facade will run trough all filters and decorates provides by modules.
- OperationsModule.apply(...) for programmatic access to the operations API.
6. Feburary 20182.5.20180205212522 with fixes for the relationship handling (#197) and an improved Home module.
4. Feburary 2018
2.5.20180203134649 is available and is all about simplifying and speeding-up relationship handling:
- @JsonApiRelationId annotation holding the identifier of a relationship. Crnk will then automatically lookup the full-fledged related resources. It is best suited if the underlying data model gives quick access to that identifier while the lookup of the full-fledged object is (much) more expensive. As further big benfit, no implementation of a relationship repository is necessary.
- @JsonApiRelation.repositoryBehavior allow to take control of how relationship repositories are implemented. While in the past they had to be implemented manually, two new options are available where a relationship repository is added implicitly and forwards calls to the adjacent resource repositories.
For more information have a look at the documentation.
Next to that there is a new end-to-end example application available based on Angular and Spring Boot: /crnk-project/crnk-example/. The documentation has also been updated in various places (in particular the first five chapters).
13. January 2018
2.4.20180112101521 is available with further Spring improvements:
- New CrnkErrorController and CrnkErrorControllerAutoConfiguration that let Spring return JSON errors in JSON API format.
- AccessDeniedExceptions are logged with WARN.
- Support for crnk.pathPrefix property to move resources into subdirectories (such as "/api/").
- RestTemplateAdapter used by crnk-client has a new constructor taking a RestTemplate as argument. Useful to pass a customized instance.
- AutoConfiguration for crnk-ui.
- Validation module makes use of the Spring validation factory, enabling the full Spring-feature set in custom validation handlers.
Next to that there are other improvements and bug fixes:
- The Operations module will only process requests with a proper application/json-patch+json accept content type.
- Added protected default constructors for RelationshipRepositoryBase and ResourceRepositoryBase sometimes needed by dependency injection frameworks like CDI.
- The "filter" request parameter can also be passed without any attribute parameter (filter=... instead of filter[attr]=...).
- JPA exceptions within the JPA module are logged as ERROR.
- New "Crnk-Compact: true" HTTP request header that will omit self, related and relationship links in the response. This can yield response size reductions of up to 65%.
- SecurityConfig.Builder of the security module allows method chaining.
8. December 2017
2.4.20171208083740 is available:
- Improved Spring integration with support for auto configuration of all modules, RestTemplate support in CrnkClient, Spring Cloud Sleuth support next to Brave and Spring MVC integration into HomeModule. Further improvements are expected in the near future. For more information have a look at the documentation.
- By default the validation modules not only does exception mapping, but also validates all incoming resources (POST and PATCH). The behavior can also be disabled by passing a flag to `ValidationModule.create(...)`.
- @crnk/angular-ngrx: has been updated to the release candidate of ngrx-json-api, providing a stable base for ngrx 4.x development. The Typescript generator has been updated accordingly.
- additional ResourceRegistry.getResourceUrl(...) methods to facilitate the computation of URLs for linking purposes.
- Invalid JSON body will now result in a 400 instead of 500 error.
- JsonProperty.Access.WRITE_ONLY to have write-only attributes.
- Typescript generator makes use of a forked process in Gradle. To perform generation, the Typescript generator has to launch the application to get access to the JSON API repositories (typically by following the JUnit setup). Since application may not always properly cleanup after themselves and Gradle daemons keep running after the builds, the new behavior prevents resource leakage and gives more robust builds.
- GET requests with application/json accept type are now also served by Crnk by default. POST and PATCH request continue to enforce application/vnd.api+json. This is a slight relaxation of the JSON API specification but in line with the more general semantic of the accept header. The behavior is configured with the crnk.config.resource.request.rejectPlainJson property.
- Both formats for linking from the official specification are now supported. See http://jsonapi.org/format/#document-links. The more simpler format continues to be the default. The behavior is configured by the crnk.config.serialize.object.links.
3. November 2017
2.3.20171103140100 is available:
- crnk-monitor-brave4 module with support for Brave 4.x and Zipkin 2.
- crnk no longer uses a trailing slash in URLs (e.g. http://localhost/api/task instead of http://localhost/api/task) in accordance with the JSON API specification. The backend ignores the trailing slash and continues to support both request formats.
- @crnk/angular-ngrx: FormBinding now carries a valid and a dirty status property of type Observable<boolean>.
- Typescript generator now produces sources that pass the most recent Typescript linting checks.
- Minor fixes/improvements to the url parameter widget in crnk-ui.
- QuerySpec.apply(...) is hardened against illegal paging offsets.
17. October 2017
2.2.20171015181129 is available:The architecture of the meta module has undergone some major updates:
- Support for dynamic repositories (see here)
- Introduction of MetaPartition to allow isolated sets of meta data. This allows, for example, to host JSON API and JPA-related (crnk-jpa) meta-data next to each other
- MetaFilter interface to intercept and modify meta data both during initialization and on request.
- MetaModuleExtension to let other Crnk modules extend the meta module.
- The resource type is used to compute name and id of meta elements. This makes the meta model more closely resemble the JSON API endpoint rather than the underyling implementation. The Typescript generator, in turn, benefits as well from this. The use of package mapping from previous versions is mostly no longer necessary.
4. October 2017
2.1.20171003194426 is available:
- ActivitiModule in crnk-activiti provides a new integration into the Activiti workflow engine to have type-safe, tailored, secure and JSON API compliant REST endpoints for Activiti objects like process instances and tasks. For more information have a look at the documentation.
- ReadOnlyResourceRepositoryBase base class for repositories that cannot be modified. Meta information in crnk-meta are adjusted accordingly (insertable, updateable, deletable get set to false).
- Filters can implement Prioritizable to introduce a priority among multiple filters.
- Changes to attributes and relationships can now be tracked by implementing ResourceModificationFilter. The filter is invoked upon an incoming request while setting up the resource objects; before the actual repository is called. Such filters are useful, for example, to implement auditing functionality.
- Improvements to the Typescript generator: generated expressions now support bidirectional relationships.
- Minor upgrade to the Spring example. The use of deprecated API has been fixed.
14. September 2017
2.0.20170914102958 is a minor feature and bug fix release.
- @OneToOne relation fix in crnk-jpa.
- Use of deprecated annotations removed from Spring example app.
- crnk-client ignores unknown relationships upon GET.
- CrnkProperties.INCLUDE_AUTOMATICALLY and CrnkProperties.INCLUDE_AUTOMATICALLY_OVERWRITE properties allow to set a default LookupIncludeBehavior that can be overriden with @JsonApiRelation.lookUp.
6. September 2017
With 2.0.20170906114618 a new major version of Crnk is available:
- @crnk/angular-ngrx is a new NPM library for Angular development with Typescript, Crnk and ngrx-json-api. Goal is to facilitate end-to-end development from backend to frontend. @crnk/angular-ngrx is not a JSON API client, but builds on top of ngrx-json-api. It bring support to bind JSON API endpoints to Angular tables and forms, take care of error handling and complements ngrx-json-api with bulk modification support using JSON PATCH and the Crnk OperationsModule. @crnk/angular-ngrx works best together with the Crnk Typescript generator. For most features, @crnk/angular-ngrx can be used with any JSON API endpoint and is not tied to Crnk backends.
- The security module has been vastly improved. A new ResourceFilter interface in crnk-core provides the basis for this and is available as API to all modules. It allows to filter entire resources, fields and relationships based on arbitrary criterias. In case of the security module, user roles decide what is allowed to a user. The filters are then applied in various areas of Crnk. HomeModule and MetaModule only show resources visible to the user. In case of the MetaModule, further insertable and updateable flags provide information what can be modified by a user. And linking to related resources is restricted accordingly.
- Code coverage at 97%. Further improvements to follow in the near-future.
- crnk-guice provides Guice dependency inject integration for Crnk similar to crnk-spring and crnk-cdi.
- Repositories, filters and modules can implement HttpRequestContextAware to get access to the underlying HttpRequest. Most notably it allows access to request and response headers; usually to do some security processing.
- Crnk annotations like @JsonApiResource and @JsonApiRelation can now be placed on interfaces next to fields, getters and setters.
- The Jackson library used by default by Crnk been upgrade to address security issues in Jackson.
- The Typescript generator has been upgraded to make use of ngrx-json-api 2.0, ngrx 4.0 and Typescript 2.4. It now provides a number of new configuration options. It can generate or omit package.json and Typescript files depending on whether the sources are directly generated into a frontend project. @crnk/angular-ngrx in crnk-client-angular-ngrx provides a further example of how to do Typescript generation without using the Gradle plugin (for more custom setups).
- The handling of resource and repository information within the Crnk engine has been refactored and the naming of some interfaces adjusted from a builder to a provider suffix (ResourceInformationProvider, RepositoryInformationProvider). The providers give the Crnk engine the necessary information about repositories, resources, attributes, types, etc. to handle requests. ResourceInformationProvider newly makes use of multiple ResourceFieldInformationProvider that collect information about fields. To the most part this means processing the various kind of annoations (Jackson, Crnk, JPA, etc.).
- The module API gained a new ModuleExtension interface and ModuleContext.addExtension(...) method. The Crnk Engine and the number of modules has grown quite rapidly in recent times and this new extension mechanism is introduced to address some limitations in the current architecture. Most notably, the mechanism allows modules to depend on one another and ensure a proper initialization order. For example, the MetaModule offers a MetaModuleExtension that is used by the JpaModule (and later ValidationModule) to enrich the meta information of resources. This includes information about binary large objects, generated primary keys, cascading and nullability; information that is irrelevant in the context of the Crnk engine but potentially of use for consumers of the meta model, like UIs. Over time it is expected that the Module API gets reduced in favor of a more modular Crnk engine and new module extensions.
- Internally, we started moving Jackson-related functionality into a JacksonModule to, over time, support serializers other than Jackson.
This release is almost fully backward compatible to Crnk 1.0. There are some minor exceptions:
- The validation module now properly computes source pointer starting with a slash, such as /data/attributes/name instead of data/attributes/name
- ResourceInformationBuilder and RepositoryInformationBuilder of the Crnk engine have been renamed to ResourceInformationProvider resp. RepositoryInformationProvider to make a clear distinction to InformationBuilder. The providers are responsible to hand information instances to the Crnk engine, while the builders are used to construct those instances.
- The deprecated ResourceRegistryBuilder has been removed. With CrnkBoot a simpler, more flexible alternative has been around for a while.
- The Module API performs stricter validation to ensure its methods are used in the proper phases of the startup process, i.e., during Module.setupModule(..), Module.init(..) or later.
- Repositories are available in the ResourceRegistry after all Module.init(..) have been invoked instead of before.
24. July 2017
1.0.20170721162741 is released:
- Support for CDI discovery of exception mappers.
- Improvements to the JAX-RS integration. Any JAX-RS service carrying a @Produce annotation of type application/vnd.api+json can benefit of the JSON API response format and exception handling to streamline mixed JAX-RS/JSON API applications.
- Added protected default constructors for all modules. Improves the CDI integration by allowing the creation of dynamic CDI proxies necessary in some scenarios.
- Resource.equals/hashCode fix. Should not affect most applications as ResourceIdentifier.equals/hashCode is primarly used.
- Typescript generator has been update. Source maps are created for the generated NPM packages. Gradle DSL improvements with the introduction of a npm configuration object. See documentation for an example.
9. July 2017
1.0.20170709163645 is the next release of Crnk coming with some major updates:
- Dependencies to Guava, Reflections and Apache Commons libraries have been removed to reduce the footprint of Crnk. Only dependencies remaining are Jackson and Jodah, with the later being very small in size.
- Crnk supports dynamic, untyped resources. Till this point, every repository had to be backed by a resource declared as Java class. This limitation is now gone. A resource can be everything from a Java class to a simple hash map with key/attribute pairs. The Module API has been extended to register such repositories. For more information see here.
- The support for dynamic, untyped resources is complemented by a more flexible handling or repositories. Repositories are held by ResourceRegistry instances. Applications are now enabled to provide custom ResourceRegistry instances in order to be in full control of the lifecycle of repositories. For example, a JDBC module maybe expose a repository for every table currently held by a schema. Adding and removing tables triggers an update of the available repositories without having to restart the application. Multiple ResourceRegistry instances can be used along each other to to maintain different repository lifecycles for different parts of the application.
- npm package versions of the generated Typescript projects have been fixated. To the consumer they are defined as peerDependencies and application are free to choose other, newer versions.
- Fix for Gradle up-to-date check of the Typescript generator plugin due to NPM interfering with the generated package.json file.
- Pagination for non-root resources has been disabled by default to prevent ambiguities in case of complex requests with inclusions and cyclic data structures. For most to all applications this should be sufficient. For more information and to modify the behavior see CrnkProperties.INCLUDE_PAGING_ENABLED.
- CrnkProperties.RETURN_404_ON_NULL has been introduced to enforce returning a 404 in case of a resource has not been found. While this is not mandated by the specification, it is common practice in most applications. It will prevent repositories returning null values from providing a 200 instead of 404 response. By default the feature is disabled. Note that throwing a ResourceNotFoundException continues to be the recommended approach of providing 404 responses.
26 June 2017
1.0.20170626133151 is released. It patches an issue in the Typescript generator whereas it can fail when it is used together with the Gradle deamon and Deltaspike.
21 June 2017
1.0.20170620140608 is available as minor patch/feature release:
|crnk-validation||OptimisticLockException.message transmitted as as JSON API error detail|
|crnk-core, crnk-client||utf-8 charset added to content-type HTTP request and responses headers|
|crnk-meta||Support for ObjectNode, ArrayNode, JsonNode as primitive types added.|
10 June 2017
1.0.20170610072810 is available!
- Initial release of the Typescript generator. It creates Typescript interfaces for resources, meta information, links information, response documents and all related objects such as enumerations and nested objects. It allows fully type-safe development of web applications including code completion and compile-type safety. Currently the combination of `ngrx-json-api`, Gradle and CDI resp. Deltaspike is supported. Have a look at the documentation for more information and get in touch for support of other frameworks.
- New pagination mechanism based on `HasMoreResourcesMetaInformation` for use cases where the computation of the total number of resources is to expensive. Have a look at the documentation for more information.
- Various documentation and web page updates.
- Gradle Build speed improvements.
1 June 2017
0.9.20170601160228 is available. Mostly a quality release to catch up with Sonar.
- All major (or worse) Sonar violations have been addressed. Fairly drastic (conditional) code coverage improvements to around 95%. There is still some more work left to do in a few modules. Further improvements will also follow once all the deprecated legacy code is removed. Goal is to have near complete coverage in the near future.
- An incubating UIModule that lets you browse the repositories with an Angular web application. Have a look at the documentation and Spring example application.
- Improvements to customize the QueySpecDeserializer to deal with unknown parameters not specified by JSON API.
- Various exceptions no longer inherit CrnkMatchingException. It is mostly an internal thing, but could lead to requests being ignored rather than throwing a proper exception, which in turn made finding such errors rather difficult.
25 May 2017
A first version 0.9.20170524133411 is released. Various contributors and existing users currently verify that everything is working smoothly.
While it is the first release, it can already be considered being production stable. The maintainers here moved forward from a mostly private code base that partially was also contributed to katharsis.io. As such there is also an easy migration path as Crnk still maintains support for the same set of main annotations and interfaces as Katharsis does. For more information see the migration guide below.