Repository navigation
Add JSON-B Support / Make Jackson optional #437
Description
Activity
Thank you for the issue.
I'm not sure about this one:
Currently annotations are used in certain places. If another library is added other annotations are additionally needed.
A user might be able to exclude a library (e.g. jackson) however they will not be able to remove these annotations which will result in a crash due to a linking failure.So as far as I can see this would mean that we effectively would have to maintain 2 models: One for Jackson and one for JSON-B.
Supporting 2 JSON libraries at least doubles the maintenance effort and I don't think that's sustainable.Additionally there's the problem with JakartaEE "standards"/application servers...
- There is no real standard. We had a lot of problems in the past how "standards" are differently implemented across application servers (e.g. JPA lazy querying behavior).
- Sometimes there is stuff missing in the standard (e.g. Same Site cookies in the past)
So if we now specify stuff in JSON-B it might work on appserver A while there is a slightly different behavior on appserver B which screws us over. That's additional maintenance effort that we would have to cover.
I also had a look at the original issue and I don't quite understand Wildfly's problem here.
https://docs.jboss.org/resteasy/docs/3.6.0.Final/userguide/html_single/index.html#d4e512
WildFly 14 supports specifying the default value for the resteasy.preferJacksonOverJsonB context property by setting a system property with the same name. Moreover, if no value is set for the context and system properties, it scans JAX-RS deployments for Jackson annotations and sets the property to true if any of those annotations is found.
Uhm just because Jackson Databind is on the classpath nobody forces Wildfly to use it for everything 😆
So I think explicitly setting
resteasy.preferJacksonOverJsonBtofalseshould be enough.Also:
Application servers should nowadays be effectively extinct and have been largely eradicated by containerized deployments. 12So I think there is currently not really a point in investing time here.
Footnotes
If the annotations have the right retentionspolicy, the classes can just have both Jackson and EE annotations.
So we just need a few tests, if the serialization output is the same.
If this works, you dont need jackson in a EE Container.If the annotations have the right retentionspolicy
Not sure what is exactly meant by this but AFAIK the retention policy is always Runtime as the Annotations are needed at runtime.
what i actually meant is, that this makes no problem when either jackson or jsonb is not available:
@JsonIgnore @JsonbTransient Map<String, Object> scalesList = new LinkedHashMap<>();but there are a few harder dependencies like:
@JsonSerialize(using = JavaScriptFunction.Serializer.class) public class JavaScriptFunction { private final String function; public JavaScriptFunction(final String function) { this.function = function; } public String getFunction() { return this.function; } public static class Serializer extends JsonSerializer<JavaScriptFunction> { @Override public void serialize( final JavaScriptFunction value, final JsonGenerator gen, final SerializerProvider serializers) throws IOException { gen.writeRawValue(value.function); } } }i think both jackson and jsonb would allow to have the serializater (or converter how its called in jsonb) in a external place like a own module: chartjs-java-model-serializer-jackson / chartjs-java-model-serializer-jsonb
but not sure if its worth
I think making Jackson optional would be a great improvement. We are using chartjs-java-model (with primefaces charts) in JSF context. Currently there is at least one "High Severity" Issue in Jackson that our tools are reporting because we are using chartjs-java-model (#482 would fix this).
When maintaining two implementations is not feasible, why not migrate to JSON-B at all? It is a major Java-Standard and there are open source implementations. Without knowing chartjs-java-models code in detail, i would guess there is everything needed available in JSON-B (or JSON-P). When it comes to different implementations my advise is to navigate around corner-cases and i would expect no problems ahead.
Currently there is at least one "High Severity" Issue in Jackson that our tools are reporting because we are using chartjs-java-model (#482 would fix this)
- This vulnerability does not affect the library as it's only relevant for
NonBlockingByteArrayJsonParserwhich is never used - We will release an updated version of the library where this is fixed shortly
- In the meantime you can manually bump the jackson databind version in your project
why not migrate to JSON-B at all?
Because Jackson Databind is the defacto standard library for JSON in the Java universe and is already present in nearly all projects. E.g. Spring Boot and Vaadin both ship it by default. For more arguments see #437 (comment)
- This vulnerability does not affect the library as it's only relevant for
I dont see real arguments in #437 (comment):
- there is a "real standard": JSR 367
- "standards" are differently implemented - only use standardized API, navigate around corner cases and i don't expect any problems ahead (JPA does not fit here, but i can relate to that)
- stuff missing in the standard - without knowing chartjs-java-models code in detail, i would guess there is everything needed available in JSON-B (or JSON-P)
Jackson Databind is the defacto standard library for JSON [...] E.g. Spring Boot and Vaadin
JSON-B is the real standard in the Java universe - I still would love to see Jackson being optional for chartjs-java-model ❤️
@tandraschko maybe primefaces could support the json-b module you proposed in this comment?
i dont plan to work on it - its a lot of work to make this possible
Reacted by DaniEll-T and Alex "Blex" BI still would love to see Jackson being optional for chartjs-java-model ❤️
i dont plan to work on it - its a lot of work to make this possible
If you really want this, you can also feel free to contact our support or propose a PR that fixes this problem in a maintainable way.
Checklist
Description
There are environments where JSON-B is available, but the chartjs model depends on Jackson.
Would be possible to support both? Like define both Jackson/Json-B annotations in the model and let the user decide which one to use for serialization.
Additional information
No response