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.