Upgrade Jackson from v1 to v2

[buehner]

I suggest to update the Jackson framework from version 1 to version 2 as you get (Spring web controller JSON serialization) problems if a SHOGun-based project has dependencies on other libraries that use jackson in version 2 (like the mapfish print lib in its latest release). In such cases, Spring would use the MappingJackson2HttpMessageConverter (as Jackson2 is available on the classpath) instead of MappingJacksonHttpMessageConverter for the JSON-serialization.

As the package name changed between v1 and v2 from org.codehaus... to com.fasterxml..., the Java classes have been adapted in this pull request.

_Attention:_

You should be careful if you are referencing the SHOGun (HEAD-) sources (or upgrading to them) in an existing SHOGun-based project (e.g. via svn:externals or similar). In such cases, you will eventually have to adapt the import declarations of your code (analogue to the changes in this PR). You should also know that the (default-) behavior of the JsonIgnore annotation has changed a little bit:

Imagine a web controller that returns a Map:

public @ResponseBody Map<String, ? extends Object> getSomeContext(...){...}

Furthermore we assume to have an entity class that makes use of the JsonIgnore annotation:

public class MyEntity {

  String a;

  @JsonIgnore
  String b;
}

If we now put an instance of MyEntity to a map that will be returned by the controller from above, there are differences between Jackson 1 and Jackson 2:

• Jackson 1 will serialize the String b although it is annotated with @JsonIgnore
• Jackson 2 will not serialize the String b

Please review and feel free to merge this PR!

[marcjansen]

I am +1 on updating, but want to postpone merging up until we have made sure this doesn't break private subprojects. I'd also like to hear from @chrismayer... he is one user that may fall into the mentioned upgrade trap.

Can you wait a little bit before merging or does this block your workflow massively?

[buehner]

I can wait and will use patches for now :smile:

[chrismayer]

I don't see a direct problem with this PR. Indeed I like to have newer versions of the libraries used. I just had some thoughts if there could be some problems by having the opposite use-case you described: Having a project that uses libs with dependencies on Jackson v1. Also a valid and thinkable scenario, isn't it? Would a v0.2 release be an option before we merge this or is this too much? So users can easily branch the version which supports Jackson v1.

Regardless how we proceed: Thank you for the PR @buehner and the exact description and warnings.

[marcjansen]

+1 for an easy v0.2 and then merge this afterwards. I motion @buehner to take care of this release.

[buehner]

@chrismayer An opposite scenario with dependencies on Jackson v1 is certainly possible, but i think that the probability for this is much lower. The latest release of Jackson v1 is from July 2013 and i don't think that it will be developed further.

I just made a new release: https://github.com/terrestris/shogun/releases/tag/v0.2

I would ask @chrismayer to merge this PR, if there is nothing to discuss anymore.

[chrismayer]

@buehner I agree that the probability for the opposite use-case will be lower. But nevertheless in many companies you cannot update your projects dependencies immediately. But now by having the v0.2 release supporting Jackson v1.x everthing should be fine and every setup should be doable.