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: #1413.
We now use a ConcurrentLruCache limited to 256 entries instead of a ConcurrentReferenceHashMap to cache Affordance instances to prevent the cache from growing unboundedly before GC kicks in.
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.
The code handling CollectionModel types now also checks for the element type being a RepresentationModel instance and checking whether the detected collection element matches the declared type.
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.
We previously didn't render the curie information if the process of curying didn't actually change the link relation if it was already given in a curied form. We now check preprocessed link relation for a curie and include the curie information if we find a curie.
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.
Let HalForms register a custom ObjectMapper customizer to allow separate customizations. If HAL and HAL Forms are supposed to be customized the same way, the same customizer can be registered on both instances. Tweak the application of the customizer to happen inside the configuration classes, not on the outside.
Prepare HalFormsConfiguration to become a fully immutable type in 1.3. Javadoc and assertion polish.
Original pull request: #1383.
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.
HalModelBuilder is now able to take Stream instances directly immediately resolving them so that clients don't have to call ….collect(Collectors.toList()) all the time. Some internal rearrangements and stricter null guarantees in EmbeddedWrappers.
Moved PropertyResolvingMappingDiscoverer into server.core package. Unified MappingDiscoverer arrangement in WebHandler and use it from there. Deprecated AnnotationBasedMappingDiscoverer to be able to make it package protected in 1.3.
Made implementation class package protected to not expose it. Avoid the use of Optional for hot code paths. Removed factory method as we only use the type internally anyway.
Removed test customizations as the discoverer is now just leniently opting out if not ApplicationContext can be found.
Original pull request: #1328.
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.
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.
[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.
