How to serialize transient fields using jackson?

Question

We use JSON serialization with Jackson to expose internal state of the system for debugging properties.

By default jackson does not serialize transient fields - but I wish to serialize them as well. How can I serialize these fields?

One way I know is to supply a getters for these fields - but I don't want to do that, as I have some getX methods that I don't want to be invoked ( for instance, there are some getters that change the objects state ).

I know I could create an annotation, but I really want to avoid it.

So my question is: Is there a way to setup jackson to serialize all the objects fields? include transient ones.

Answer 1

My solution with Jackson 2.4.3:

  private static final ObjectMapper mapper =
        new ObjectMapper(){{

            Hibernate4Module module = new Hibernate4Module();
            module.disable(Hibernate4Module.Feature.USE_TRANSIENT_ANNOTATION);
            registerModule(module);

        }};

Answer 2

I don't think Jackson supports any type of configuration to enable it to serialize a transient field. There's an open issue to add that feature, but it's old and hasn't been addressed (as far as I can tell): http://jira.codehaus.org/browse/JACKSON-623

So my question is: Is there a way to setup jackson to serialize all the objects fields? include transient ones.

So to answer your question, no.

Some other Java JSON tools, such as GSON do support a configuration option to serialize transient fields. If you can use another tool, you might look into that (for GSON, see: https://sites.google.com/site/gson/gson-user-guide).

To expand a little, you might try a different approach.

First, You shouldn't try to serialize a transient field. After all the definition of transient is "don't serialize this." Nevertheless I can think of a few specific situations where it might be necessary, or at least convenient (like when working with code you can't modify or such). Still, in 99% of cases, the answer is don't do that. Change the field so that it's not transient if you need to serialize it. If you have multiple contexts where you use the same field, and you want it serialized in one (JSON, for example), and not serialized in another (java.io, for example) then you should create a custom serializer for the case where you don't want it, rather than abuse the keyword.

Second, as to using a getter and having "some getters that change the objects state," you should try to avoid that too. That can lead to various unintended consequences. And, technically, that's not a getter, that's a setter. What I mean is, if it mutates state, you've got a mutator (setter) rather than accessor (getter), even if you name it following the "get" convention and return some stuff.