Switched from using regular expressions to a simple manual parsing algorithm for the attributes attached to a link. Adapt a couple of broken tests that previously erroneously worked.
Switched to manual parsing of template variables as regular expressions can contain { and } characters which makes matching variables using these as delimiters impossible.
Related ticket: #1414.
It doesn't make sense to wrap an object to be rendered as value into an EntityModel as the latter will end up as JSON Object and thus, the representation of the target object *needs* to consist of key-value pairs.
Previously we just produced invalid JSON which ultimately failed as well.
By removing our need to use bintray for releases and instead deploying directly to maven central, we can reduce the risk of issues.
Related issue: #1417, #1419
We now remove potentially used regular expression matchers from template variables to avoid the to show up in links generated for the templates.
Backport of #1412.
Also:
Spring Doc Resource 0.2.2 -> 0.2.5
Jackson 2.11.0 -> 2.11.3
JUnit 5.6.2 -> 5.6.3
Reactor Dysprosium SR12 -> Dysprosium SR15
Kotlin 1.3.71 -> 1.3.72
No Kotlin coroutines and Mockk upgrades as they seem to be binary incompatible
CollectionModelProcessorWrapper erroneously returned a raw type in case a CollectionModel type assignment check failed which rendered the element type verification to always match as it's effectively compared against Object.
We're now returning null to rather proceed with the next candidate type.
Original ticket: #1379.
We now use a custom serializer for EntityModel.getContent() as we need that to still return the Map content for programmatic clients. The serializer skips maps entirely and programmatically unwraps all other content.
A simple Converter (@JsonSerialize(convert = …)) to filter Maps unfortunately didn't do the trick as that causes a a delegating serializer to be registered for the property and @JsonUnwrapped stops working as it's designed to work with bean serializers only.
Adapted test cases accordingly.
Original pull request: #1353.
Custom media types do NOT require registering a MediaTypeConfigurationProvider implementation with spring.factories. The reference docs must be updated to illustrate this. Also add to the javadocs so users are properly warned.
Original issue: #1304
According to https://github.com/blongden/vnd.error, logref is for "expressing a (numeric/alpha/alphanumeric) identifier". This patches `VndError` to support both strings and integers, ensuring each serializes properly.
NOTE: `VndErrors` has been deprecated due to the spec itself being dead since 2014. However, it must be supported until fully removed from Spring HATEOAS.
Backport of: #1291.
Original pull request: #1293.
Previously the parsing of link relations had assumed that a curie relation only consists of a single colon, thus, that a split by colon would always end up in two elements and only re-assembled these two elements. In case a URI that contains multiple colons handed into the parsing method, further segments had been dropped. We now remain everything following the first colon as local part of the URI.
Also, we now detect IANA registered URI schemes [0] and consider source relations starting with those as uncuried ones.
Related ticket: #1314.
[0] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
We now avoid creating the UriTemplate instance for a Link if the Link does not contain curly braces in the first place. That allows us to remove the cache within UriTemplate in the first place.
Related tickets: #1287.
