fasterxml/jackson-datatypes-misc

Collection of common Jackson datatype modules not part of other multi-project repos

jackson-datatypes-misc's Issues

Add alternate constructor in `JSONPModule`/`JSR353Module` to take `JsonProvider`

(see PR #10 for background)

It seems useful to add overloads for module constructors of JSR-353/Jakarta-JSONP modules, to allow users to explicitly pass JsonProvider instance to use, and not rely on auto-discovery via SPI. This is especially useful since it appears that "jakarta-jsonp" implementation has a classpath conflict with old jsr-353 implementation so that SPI fails if both new and old impl jars are in classpath (which should be fine; they are in different Java packages -- but isn't).

Improve error handling of "joda-money" `MoneyDeserializer`, `CurrencyUnitDeserializer`

As of 2.12, no validation is done for case of missing monetary amount or unit, and failure propagates as NPE -- unit test even verifies that. But that seems like a pretty bad user experience. Instead, let's validate this properly and indicate using DeserializationContext.reportInputMismatch().
Probably also makes sense to check handling of currency unit as well; seems better to give Jackson-specific exception for unknown unit than expose library-specific one.

Add `jakarta` classifier version of `jackson-datatype-jsr353` to work with new Jakarta-based JSON-P

Hi!
Do you plan to support Jakarta JSON Processing?

The JavaEE packages are now being maintained and developed by the Jakarta project and Jakarta JSON v2.0.0 has been released recently. Unfortunately, v2.0.0 is not backwards compatible with 1.x.x because of package name change. 

Improvement: Allow selection of amount representation for individual Joda Money fields

Intro

For Joda Money module, we have the possibility to select the amount representation on module level. Amount representation varies from API to API. In projects that involve integration with many APIs it would be beneficial to allow such selection on field-level. This ticket collects possible approaches.

Appoaches

To achieve field-level selection we could:

1. Leverage @JsonFormat's shape (see comment #1 and comment #2):

@JsonFormat(shape = NUMBER_INT)
Money grandTotal;

Characteristics:

• This has the benefit of leveraging existing annotation related to formatting without the need to introduce a new one.
• We will still have to document the behavior of @JsonFormat on Money (de)serializers as it won't be obvious what shapes are supported and what effect they have.
• It might be a bit confusing to some, as the annotation doesn't influence the field itself but rather a particular nested property.
• It doesn't help with potential further extensions. As an example, the naming of the properties varies from API to API - I've integrated systems with services using currencyCode instead of currency and value instead of amount as the names of the individual properties carrying the monetary amount. If we wanted to allow customization of the names in the future, most likely we wouldn't do that via @JsonFormat annotation but rather a dedicated one.

2. Introduce dedicated annotation (here: @JsonMoney) allowing selection of amount representation (see comment):

@JsonMoney(amountRepresentation = MINOR_CURRENCY_UNIT)
Money grandTotal;

Characteristics:

• We have to introduce a new annotation, mention it in README and document in JavaDocs.
• We are open for further extension (argument with custom property names above).

3. Do a mix of the two - extend @JsonFormat to allow passing (de)serializer-specific annotations (here: via new with attribute):

@JsonFormat(with = @JsonMoney(amountRepresentation = MINOR_CURRENCY_UNIT))
Money grandTotal;

Characteristics:

• We configure the format the way users might be used to do it.
• We are open for further extension (argument with custom property names above).
• We have to introduce a new annotation, mention it in README and document in JavaDocs.
• We have to modify @JsonFormat just for the sake of passing custom annotations.

Implementation

Regardless of the approach, most likely Contextual(De)Serializer would be used to build the (de)serializer.

Discussion

Do you see some more characteristics of these approaches?
Do you see a clear winner? (I'm slightly leaning towards approach 2)

Of course we don't have to pull the trigger now - might as well keep this open until we have more insights or convictions. Just wanted to write down my thoughts.

Rename "com.fasterxml.jackson" -> "tools.jackson"

As the main task for JSTEP-1 (https://github.com/FasterXML/jackson-future-ideas/wiki/JSTEP-1) we need to:

1. Change Maven package group ids from "com.fasterxml.jackson.datatype to "tools.jackson.datatype"
2. Change Java Package names from "com.fasterxml.jackson.datatype" to "tools.jackson.datatype"

as well as all secondary changes for OSGi and Java module system.

Input `null` being deserialized as Java null value instead of `JsonValue.NULL`

(note: re-try fix for FasterXML/jackson-datatype-jsr353#16)

So, as per earlier take, JSON null should ideally map to JsonValue.NULL.

However! If nominal target type is NOT JsonValue but subtype like JsonObject, this is not possible and value MUST remain Java null.

Regression in 2.15: parsing double value returns BigDecimal instead of Double

I'm filing this issue as the result of conversation in pull request:
#32

Here is the test:

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.datatype.jsonorg.JsonOrgModule;
import org.json.JSONObject;
import org.junit.Assert;
import org.junit.Test;

public class JsonDoubleTest {

    @Test
    public void testDoubleParsing() throws Exception {
        ObjectMapper objectMapper = new ObjectMapper().registerModule(new JsonOrgModule());
        JSONObject jsonObject = objectMapper.readValue("{\"value\": 0.5 }", JSONObject.class);
        Assert.assertEquals("java.lang.Double", jsonObject.get("value").getClass().getCanonicalName());
    }
}

When I run it with Jackson 2.13.4 then it passes. When I run it with Jackson 2.15.0, it fails with error:

org.junit.ComparisonFailure: 
Expected :java.lang.Double
Actual   :java.math.BigDecimal

Deserializing a JSON Merge Patch fails when the input is not a JSON object

A JSON Merge Patch (RFC 7396) is typically a JSON object, and Jackson (at least versions 2.13 and 2.14.0-RC2) deserializes JSON objects to javax.json.JsonMergePatch as expected.

However, when deserializing input that is not a JSON object, Jackson throws an exception, with the exact exception depending on whether the input is a JSON array or scalar.

RFC 7396 does not limit the JSON Merge Patch format to JSON Objects and in fact handles the case where the merge patch is not an object explicitly in the pseudocode function presented in Section 2 of the RFC. More importantly, Jackson's current behavior is somewhat awkward for instance when using JsonMergePatch directly in a Spring controller like so:

@PatchMapping
ResponseEntity<?> patch(@RequestBody JsonMergePatch mergePatch) { ... }

When called with a body that is a JSON array, this throws an NPE, with a typical Spring exception handler would convert into a response with HTTP status code 500.

IMO, the preferred fix would be to call JsonValueDeserializer#deserialize instead of _deserializeObject from JsonMergePatchDeserializer (see PR #26), which would return a JsonValue. Alternatively, _deserializeObject could check whether the current token is START_OBJECT and return an empty JsonObject.

Any idea/indication when v2.14 will be released?

The changes in 2.14 that have been merged from that branch into the master branch seem really good - for eg, we are looking for the serialization/deserialization changes that were done.

Unfortunately, since this hasnt been released, we ended up cobbling some code (not the best) to make our code work. But, would love if 2.14 can be released soon so that we can remove our wrapper code.

Update `org.json` dependency from `20190722` to `20230227`

Looks like our org.json dependency is bit old; there may be CVEs/vulns reported against intermediate versions and API should be compatible so let's just upgrade (for 2.15.0).

Uncovered test in JSONP module

The test case com.fasterxml.jackson.datatype.jsonp.TestVersions is failing, but because of its class name is currently being ignored by the build.

[jsr-353] Add apache karaf features to jackson

This is the part of FasterXML/jackson-databind#2434 that relates to changes to the jackson-datatype-jsr353 project.

Add delegating serializers for `JsonPatch` and `JsonMergePatch`

To simplify the serialization of json-p patch objects, proposing adding delegating serializers for JsonPatch>JsonArray and JsonMergePatch>JsonValue

It takes extra steps to convert a patch into a type that has a serializer available.

        addSerializer(JsonPatch.class, new StdDelegatingSerializer(new Converter<JsonPatch, JsonArray>() {
            @Override
            public JsonArray convert(JsonPatch value) {
                return value.toJsonArray();
            }
            @Override
            public JavaType getInputType(TypeFactory typeFactory) {
                return typeFactory.constructFromCanonical(JsonPatch.class.getName());
            }
            @Override
            public JavaType getOutputType(TypeFactory typeFactory) {
                return typeFactory.constructFromCanonical(JsonArray.class.getName());
            }
        }));

Add `javax.money` support (from `zalando / jackson-datatype-money`)

(from: zalando/jackson-datatype-money#224)

Author existing jackson-datatype-money seems supportive of the idea, to help release new versions, so it would be nice to integrate this, ideally in time for Jackson 2.12.0 (but if not immediate, soon after is fine too).

JsonValue.NULL deserialization has different behaviours with constructor properties vs public properties

Describe the bug
Deserializing a missing property to JsonValue while using constructor properties should set java null instead JsonValue.null, this when deserializing to class with public properties works wel..

Version information
2.13.1

To Reproduce
JsonValueTest.txt

Expected behavior
When missing property map to java null and when property is null map to JsonValue.NULL.

Additional context
We are using this to know when we when we should do nothing (java null) and when we must set the value to null in database (JsonValue.NULL)

Jackson JSR353 library is using wrong module name for javax json api

In the jsr353 module, the javax json api module require statement is using the wrong module name, resulting in this error:

java.lang.module.FindException: Module javax.json.api not found, required by com.fasterxml.jackson.datatype.jsr353

The "correct" name (in quotes because there is no consistency in the jakarta projects on how they named the javax modules :( ) is java.json.

So it should be

requires java.json;

rather than

requires javax.json.api;