slifty slifty - 2 months ago 10
Java Question

Why is Jersey ignoring my Jackson annotations?

I'm using Jersey and Jackson to create a simple JSON API.

Some of the objects being serialized have custom enum fields. By default, those enums are converted to a string based on the enum vale -- I would like the enums to have slightly more complex serializations.

I'm using Jackson annotations within the enum, but the endpoint seems to be ignoring them. I've been spinning my wheels trying to figure out where the issue is, and now I turn to you.

Enum Code

package org.example.code;

import com.fasterxml.jackson.annotation.JsonFormat;
import com.fasterxml.jackson.annotation.JsonProperty;

@JsonFormat(shape= JsonFormat.Shape.OBJECT)
public enum ExampleEnum {
YES (1, "Yes indeed"),
NO (2, "No way buddy")

private final Integer code;
private final String description;

ExampleEnum(final Integer code, final String description) {
this.code = code;
this.description = description;

public Integer getCode() {
return code;
public String getDescription() {
return description;

API Code

package org.example.webservice.impl;


import org.example.code.ExampleEnum;

public class ExampleService {
public ExampleEnum getExampleEnum() {
return ExampleEnum.YES;

When I call the endpoint
the output is

What I want is the output to be something along the lines of
{ code: 1, description: "Yes indeed" }

Configuration files are below...


<project xmlns="" xmlns:xsi=""


<name>example API</name>










<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0"
<display-name>Example Servlet</display-name>
<servlet-name>Example Servlet</servlet-name>
<servlet-name>Example Servlet</servlet-name>


So a Few things:

  • com.sun.jersey.api.json.POJOMappingFeature is for Jersey 1.x, so you can get rid of that.

  • MOXy is the default provider in Glassfish, so if you want to use Jackson, then you need to disable MOXy. You can do so by adding this <init-param>

  • Then as @Alexey Gavrilov pointed out, add the Jackson provider

  • You can register this provider by adding the package to the packages to scan


Another thing that is unrelated to this issue that I might point out, is that Glassfish already has a Jersey implementation, which is a very old 2.x version, maybe 2.0. When you add runtime Jersey dependencies, they might conflict. I would do one of two things, either put all the Jersey dependencies in a provided <scope> or if you have requirements for later version functionality, you may want to look into updating the Jersey version in Glassfish. Have a look at Updating Jersey 2 in GlassFish 4