Possible alternative source of JSON

[Benson Margulies <bi...@gmail.com>]

http://wiki.fasterxml.com/JacksonInFiveMinutes

It looks to me as if a Jackson 'provider' would be a pretty straightforward
construction. To be clear, there's be no CXF DataBinding in the process at
all. Jackson maps pojos to JSON and vica versa.

The plus side of this is that it would yield, if successful, 'natural' json,
unencrusted with namespace glop, in both directions.

The minus side of this would be that it doesn't help those people who want a
JSON JAX-RS endpoint as a sort of instant side-effect of their preexisting
stack of JAXB @nnotations or Aegis XML files or whatever.

Personally, I think that I'd be coding something a whole lot more useful by
adding this than by putting more lipstick on the pig of producing and
consuming extremely ugly JSON via Aegis.

Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already
does the job, why do all that work?

Not to mention the fact that Tatu is likely to prove responsive in case of
need.

Re: Possible alternative source of JSON

[Benson Margulies <bi...@gmail.com>]

I'm going to start an omnibus thread.

On Mon, Sep 7, 2009 at 5:20 AM, Sergey Beryozkin <sb...@progress.com>wrote:

>
>
>  http://wiki.fasterxml.com/JacksonInFiveMinutes
>>
>> It looks to me as if a Jackson 'provider' would be a pretty
>> straightforward
>> construction. To be clear, there's be no CXF DataBinding in the process at
>> all. Jackson maps pojos to JSON and vica versa.
>>
>> The plus side of this is that it would yield, if successful, 'natural'
>> json,
>> unencrusted with namespace glop, in both directions.
>>
>> The minus side of this would be that it doesn't help those people who want
>> a
>> JSON JAX-RS endpoint as a sort of instant side-effect of their preexisting
>> stack of JAXB @nnotations or Aegis XML files or whatever.
>>
>> Personally, I think that I'd be coding something a whole lot more useful
>> by
>> adding this than by putting more lipstick on the pig of producing and
>> consuming extremely ugly JSON via Aegis.
>>
>> Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already
>> does the job, why do all that work?
>>
>
> Let me ask you the other question. If users have already done Aegis, why
> would they want to bring in Jackson ?
> 'unqualified' Aegis will do exactly what they want too, as far as dealing
> with explicit collections/maps is concerned
>
> cheers, Sergey
>
>
>
>> Not to mention the fact that Tatu is likely to prove responsive in case of
>> need.
>>
>>

Re: Possible alternative source of JSON

[Sergey Beryozkin <sb...@progress.com>]

> http://wiki.fasterxml.com/JacksonInFiveMinutes
> 
> It looks to me as if a Jackson 'provider' would be a pretty straightforward
> construction. To be clear, there's be no CXF DataBinding in the process at
> all. Jackson maps pojos to JSON and vica versa.
> 
> The plus side of this is that it would yield, if successful, 'natural' json,
> unencrusted with namespace glop, in both directions.
> 
> The minus side of this would be that it doesn't help those people who want a
> JSON JAX-RS endpoint as a sort of instant side-effect of their preexisting
> stack of JAXB @nnotations or Aegis XML files or whatever.
> 
> Personally, I think that I'd be coding something a whole lot more useful by
> adding this than by putting more lipstick on the pig of producing and
> consuming extremely ugly JSON via Aegis.
> 
> Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already
> does the job, why do all that work?

Let me ask you the other question. If users have already done Aegis, why would they want to bring in Jackson ?
'unqualified' Aegis will do exactly what they want too, as far as dealing with explicit collections/maps is concerned

cheers, Sergey

> 
> Not to mention the fact that Tatu is likely to prove responsive in case of
> need.
>

Re: Possible alternative source of JSON

[Benson Margulies <bi...@gmail.com>]

Sergey,

I think it is important that we work toward a clearly stated goal here. You
originally recruited me to plug in Aegis to JAX-RS because, as I recall, the
DOSGi people wanted a way to use JAX-RS without the burden of JAX-B and
other related components.

Now, on the one hand, Aegis+Jettison produces very ugly JSON, and we do not
have any design at hand to support a read side without making even uglier
demands on the producers of the JSON we would read. It doesn't produce such
beautiful XML, either.

On the other hand, the Jackson components are small and produce clean JSON,
and if Tatu hasn't packed them up as OSGI bundles yet, I'm sure he will.
Heck, I'd rather spend time on that with him that adding more lipstick to a
distinctively porcine combination of Aegis and Jettison.

If I've misremembered or mistated the goal here, please correct me.

--benson

Re: Possible alternative source of JSON

[Benson Margulies <bi...@gmail.com>]

They don't have to wrap it. There's a full JAX-RS 1.0 provider provided. I
added a test for our cooperation with it to the systests.

Why don't we just endorse it over our on JSON provider? It makes cleaner
JSON, and is smaller, lighter, faster and more flexible.


On Sun, Sep 6, 2009 at 6:11 PM, Sergey Beryozkin <sb...@progress.com>wrote:

> Users can easily wrap Jackson if they prefer. We can add a property to
> existing providers which will allow for namespaces be dropped altogether
> during the serialization if users prefer to parse JSON manually.
>
> Cheers, Sergey
>
> -----Original Message-----
> From: Benson Margulies [mailto:bimargulies@gmail.com]
> Sent: 05 September 2009 22:40
> To: CXF Dev
> Subject: Possible alternative source of JSON
>
> http://wiki.fasterxml.com/JacksonInFiveMinutes
>
> It looks to me as if a Jackson 'provider' would be a pretty
> straightforward
> construction. To be clear, there's be no CXF DataBinding in the process
> at
> all. Jackson maps pojos to JSON and vica versa.
>
> The plus side of this is that it would yield, if successful, 'natural'
> json,
> unencrusted with namespace glop, in both directions.
>
> The minus side of this would be that it doesn't help those people who
> want a
> JSON JAX-RS endpoint as a sort of instant side-effect of their
> preexisting
> stack of JAXB @nnotations or Aegis XML files or whatever.
>
> Personally, I think that I'd be coding something a whole lot more useful
> by
> adding this than by putting more lipstick on the pig of producing and
> consuming extremely ugly JSON via Aegis.
>
> Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already
> does the job, why do all that work?
>
> Not to mention the fact that Tatu is likely to prove responsive in case
> of
> need.
>

RE: Possible alternative source of JSON

[Sergey Beryozkin <sb...@progress.com>]

Users can easily wrap Jackson if they prefer. We can add a property to
existing providers which will allow for namespaces be dropped altogether
during the serialization if users prefer to parse JSON manually. 

Cheers, Sergey

-----Original Message-----
From: Benson Margulies [mailto:bimargulies@gmail.com] 
Sent: 05 September 2009 22:40
To: CXF Dev
Subject: Possible alternative source of JSON

http://wiki.fasterxml.com/JacksonInFiveMinutes

It looks to me as if a Jackson 'provider' would be a pretty
straightforward
construction. To be clear, there's be no CXF DataBinding in the process
at
all. Jackson maps pojos to JSON and vica versa.

The plus side of this is that it would yield, if successful, 'natural'
json,
unencrusted with namespace glop, in both directions.

The minus side of this would be that it doesn't help those people who
want a
JSON JAX-RS endpoint as a sort of instant side-effect of their
preexisting
stack of JAXB @nnotations or Aegis XML files or whatever.

Personally, I think that I'd be coding something a whole lot more useful
by
adding this than by putting more lipstick on the pig of producing and
consuming extremely ugly JSON via Aegis.

Admittedly, 'unqualified' Aegis would be helpful, but if Jackson already
does the job, why do all that work?

Not to mention the fact that Tatu is likely to prove responsive in case
of
need.