This is the opposite of what most Spring users are clamoring to do, but I was wondering if its possible to specify that Jackson 1.9.7 be used by Spring (3.1.2) and NOT Jackson 2+.
The project I'm working on relies on other projects that use Jackson 2, so it get pulls in as a transitive dependency. From there Spring picks it up to handle JSON serialization. This in turn borks my application because of custom annotations I've created that require the Jackson version be 1.9.7.
Not sure if this helps, but note that you can also add both Jackson 1 and Jackson 2 annotations in value classes. I have done this at work, to help transition from Jackson 1.9 to Jackson 2.x. And in fact different parts of code use different version: unit test helper methods were migrated first, and later on production code, section by section.
As with library version, use of two sets of annotations is not optimal, but doing so may help reduce risk of version upgrade.
Finally, it is also possible to use an AnnotationIntrospector that can use both sets of annotations (I don't have a link at hand, but I know a Jackson user published version he created); usually Jackson 2 JacksonAnnotationIntrospector that also recognizes Jackson 1 annotations. This avoids duplication of annotations and makes it possible to upgrade code first, then convert annotations.
Related
I am writing a java-library that will be included included as a dependency in other projects. I want some of the library's classes to de/serializable with Jackson's ObjectMapper. Out of habit, I have used annotations to tell Jackson how to de/serialize my classes.
Will the annotations' functionality get exported by the library (like api)?
Will a dependent application be able to use the an ObjectMapper created by the default constructor? Is any further configuration necessary?
Can I put the annotations into a custom Jackson Module for dependent applications to register with their ObjectMapper?
I have been very surprised to find a dearth of documentation for this use case.
Can we use lombok framework in embedded Java? Like midlets or implementations where we need only core java.
Yes, I expect that you can use lombok in embedded Java.
Lombok is a compile time dependency, and not related to any deployment platform.
You might want to modify lombok.config and instruct lombok to not generate #ConstructorProperties using lombok.anyConstructor.suppressConstructorProperties=true (in the upcoming release, this will be the default behavior and deprecated), since I expect that that is not available at runtime.
Also, the generated code is optimized for hotspot, so you might also want to configure lombok.equalsAndHashCode.doNotUseGetters=true and lombok.toString.doNotUseGetters=true to use direct field access instead of getters.
Disclosure: I am a lombok developer.
I've got a problem with resources linking in Dropwizard. With JAX-RS 2.0 we've got magical javax.ws.rs.core.Link class which with it's builder can do almost all the work for you. Unfortunately Dropwizard 0.7.1 doesn't depend on the new 2.0 API, but on the old javax.ws.rs:jsr311-api API, which can't handle linking. Or can it? This is the problem I want to solve with Dropwizard. I probably have two ways to do it and I don't know if any of them is valid:
Option 1: I add JAX-RS 2.0 dependency to my project. Voila! I've got Link. But the problem is, that it doesn't work well with old implementations from Jersey - I got AbstractMethodException from UriBuilder, which apparently changed from version 1 to 2. So the answer is to supply new implementations. Can I do it? If yes, than how can I do it? Will new implementations work with dropwizard well?
Option 2: I can just add some other resource linking to dropwizard. Is there some other linking standard/library? I can't use jersey-declarative-linking because it mixes representations with the resources (the linking takes place in representations), and I want my representations not to know a thing about resources layer. So is there another linking standard for Dropwizard, Jersey and JAX-RS 1?
I've finally found an answer to my question.
Option 2 was a dead end. There was no other jax-rs-2-like linking library to either dropwizard or jersey itself.
Option one also was hard to do, but fortunatelly yesterday dropwizard released version 0.8.0-rc1 of their framework, which depends on jersey 2, which is the implementation of JAX-RS 2.0. So for all of you that want to have HATEOAS in dropwizard, version 0.8.0 is for you.
i am developing a restful service with tomcat 7 and jdk 1.6. for json handling i am using jackson 2.4.2 and it works fine except when i try and deserialise an object (that it has no trouble serialising).
the error is:
java.lang.ClassNotFoundException: org.codehaus.jackson.JsonFactory
which is the place where jackson 1.x kept that particular class. my jackson 2.4.2 has it at
com.fasterxml.jackson.core.JsonFactory
i have no idea as to why it is trying to link the old class. i never used jackson 1.x.
what i use:
asm-3.3.1
commons-io-2.4
jackson-core-2.4.2
jackson-databind-2.4.2
jersey-bundle-1.18
mysql-connector-java-5.1.27
and
com.fasterxml.jackson.annotation
which i have taken from github. what library could be trying to import the old jackson module? any help would be much appreciated.
The issue certainly comes from trying to use Jackson 1.x ObjectMapper and missing underlying JsonFactory for 1.x. Since these come from difference jars (jackson-mapper-asl vs jackson-core-asl), it is likely that somehow one is missing.
Now, since you are not directly using Jackson 1.x, question is who is: perhaps jersey is relying on 1.x?
So there are two related questions: (a) if Jackson 1.x is needed, to bring in core jar as well, or (b) how to remove use of Jackson 1.x altogether.
Note that technically it is quite possible to use both 1.x and 2.x versions of Jackson, since 2.x was specifically designed to be able to co-exist. This to make upgrades easier, and allow gradual (component-by-component) upgrading.
I produce json using resteasy.
Everything works fine but... I can't order the parameters of my generated json:
In my serialized class, I have the following anotations:
#XmlRootElement
#XmlType(propOrder={"foo1", "foo2", "foo3"})
in my generated json, i get:
{"foo2":"bar2","foo1":"bar1","foo3":""}
There is the following dependency in my pom.xml
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jackson-provider</artifactId>
<version>2.2.0.GA</version>
</dependency>
any idea?
A simple answer is that "it does not matter" -- ordering of properties in JSON Object has no significance, so libraries and frameworks are free to output them in whatever order they want to.
But more complex answer would be along lines of trying to maybe use Jackson's own #JsonPropertyOrder annotation, which should work. Unless you absolutely must use JAXB annotations, that might solve your problem.
Even so, this JAXB annotation should be supported by Jackson, when JAXB annotation mode is enabled. So if you need to use JAXB annotations, you need to try to figure out why support is not enabled. It may or may not be enabled with RESTeasy, since Jackson itself does not use them by default (i.e. framework has to explicitly enable then).
This is fixed with Jackson 2.3.2. Upgrade and your problems go away.