Hi Tim,
Jersey did not started using Jackson as the default, as we do not want
to break the backward compatibility.
Please see attached project, where the JAXB bean, MyBean, gets
serialized to JSON without the nilString value unless
you explicitly turn Jackson POJO mapping on in the Main class. Just
uncomment the following line there to see
the difference:
//initParams.put(JSONConfiguration.FEATURE_POJO_MAPPING, "true");
Maybe your issue is, you want to utilize Jackson for non-JAXB classes
and JAXB for JAXB beans
at the same application?
Is that the issue?
~Jakub
On 10/05/2010 10:24 PM, Tim McCune wrote:
> Figured out what was going on here. I was hooking up my own
> ContextResolver for Jackson's ObjectMapper, so that I could tell it to
> stop generating all of the "null" properties in the output. Turned
> out that simply constructing a new ObjectMapper() used only the
> Jackson annotations, and ignored all of the JAXB annotations, as you
> suggested. So I ended up doing this:
>
> MapperConfigurator configurator = new MapperConfigurator(null,
> new Annotations[] {Annotations.JAXB});
> // This Feature has been deprecated in Jackson, in favor of calling
> // setSerializationInclusion(JsonSerialize.Inclusion.NON_NULL) on
> // the serializationConfig. But the wonderful
> MapperConfigurator doesn't
> // actually set its configuredMapper to a non-null value until
> you call
> // configure() once. So since we've got nothing else to
> configure, and
> // since the deprecated feature can be set through a call to the
> configure()
> // method, we just use it.
>
> configurator.configure(SerializationConfig.Feature.WRITE_NULL_PROPERTIES,
> false);
> _mapper = configurator.getConfiguredMapper();
>
> All of these hoops to jump through just because the switch to use
> Jackson for JSON output now fills the objects up with "null"s for all
> properties that aren't set. I suppose that this could be interpreted
> as a "feature", but I fail to see any value in having all the "null"s
> in the output. I realize that this stupidity is coming from Jackson,
> and not Jersey, but it has now crept into Jersey as well, since
> they've started using Jackson as the default code for dealing with
> JSON. I'm inclined to file bugs with both projects, but wanted to see
> if anyone could offer any suggestions about what I might be missing
> before I do.
>
> Thanks again for the help.
>
> --Tim
>
> On Thu, Sep 30, 2010 at 3:05 PM, Tatu Saloranta <tsaloranta_at_gmail.com
> <mailto:tsaloranta_at_gmail.com>> wrote:
>
> On Thu, Sep 30, 2010 at 2:27 PM, Tim McCune <tim_at_mccune.name
> <mailto:tim_at_mccune.name>> wrote:
> > Hmm...actually, I'm seeing a lot of behavior that I wouldn't
> expect, and
> > it's making me wonder if I'm doing something wrong. Jersey
> seems to be
> > skipping my JAXB annotations completely. My @XmlTransient
> properties are
> > showing up in my JSON output, and my @XmlJavaTypeAdapters are
> not being
> > used.
> >
> > Has Jersey changed its default JSON marshalling to no longer go
> through
> > JAXB? Or am I doing something wrong? I haven't changed any
> code; I simply
> > upgraded Jersey from 1.1.4.1 to 1.4.
>
> I could be wrong, but symptoms would fit with using Jackson configured
> to only use its own annotations (default), not with JAXB or
> Jackson+JAXB annotations.
> Jackon JAX-rs package comes with pre-configured alternatives for both;
> JacksonJaxbJsonProvider and JacksonJsonProvider.
> Maybe Jersey 1.4 uses latter, not former?
>
> As to changes, I don't know for sure but I think that existing json
> mappers still work the way they used to, and it's just question of
> which mapper is used by default.
> For user it is of course a significant change.
>
> -+ Tatu +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> <mailto:users-unsubscribe_at_jersey.dev.java.net>
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> <mailto:users-help_at_jersey.dev.java.net>
>
>