Hmm, I haven't made any changes to my application to enable Jackson. Jersey
just started using Jackson when I upgraded from 1.1.5.1 to 1.4. So maybe
there is some unintended side-effect of the way that I've always used Jersey
that is enabling Jackson? At any rate, with Jackson doing the marshalling,
I'd still expect it to not output the "null"s, which it seems to be doing
when it's turned on in Jersey, regardless of whether or not it's actually
supposed to be turned on. :)
On Wed, Oct 6, 2010 at 1:34 AM, Jakub Podlesak <Jakub.Podlesak_at_sun.com>wrote:
>
> 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>wrote:
>
>> On Thu, Sep 30, 2010 at 2:27 PM, Tim McCune <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
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>>
>
>