Hi Stephan,
On Fri, Apr 04, 2008 at 06:19:25PM +0200, Stephan Schmidt wrote:
> Hi Jakub,
>
> thanks for the code.
>
> The problems I wanted to solve though are different, and as far as I know
> cannot be solved with JAXB:
>
> - Have different JSON representations for different calls (with shops,
> without shops, aliasing names etc.)
> Can I have different JSON representations for one Java object with JAXB?
Nope. You would need to have different beans.
> - Usually there is no 1:1 mapping from business domain objects to data
> needed in the client. Often
> the UI does need aggregated or mapped data which is not part of the
> business domain object.
> I didn't want to create lots of Java objects and populate them just for
> the sake of serializing
> them to JSON.
I see. I like the builder approach. Just wanted to show that
if you do not want a different representation (as you mentioned at the 1st point),
JAXB approach could work as well.
Besides serializing out (Java->JSON), do you also need to deserialize back (JSON->Java)?
What is your approach there?
~Jakub
> - Lean JSON as possible
>
> Bye
> -stephan
>
> On Fri, Apr 4, 2008 at 5:11 PM, Jakub Podlesak <Jakub.Podlesak_at_sun.com>
> wrote:
>
> >
> > Hi Stephan,
> >
> > On Fri, Apr 04, 2008 at 01:01:44PM +0200, Stephan Schmidt wrote:
> > > Hi,
> > >
> > > just my two cents, I don't like BadgerFish and generated JSON from
> > objects,
> > > because several requests might return different JSON representations,
> > >
> > >
> > http://stephan.reposita.org/archives/2008/04/04/rest-lean-json-and-xml-from-the-same-code/
> >
> > With current Jersey version you can do the same (with default config) and
> > as a benefit you would
> > also have the ability to transform the JSON data back to java.
> > You notice only Java to JSON binding in your post.
> >
> > Besides that you will IMHO have an easier way to populate your data into
> > your java beans.
> >
> > You might want to try out the following:
> >
> > @Path("/list")
> > public class ShoppingListResource {
> >
> > @XmlRootElement
> > public static class Item {
> > public String id;
> > public int price;
> > public String shop;
> > public String description;
> >
> > public Item(String id, int price, String shop, String description)
> > {
> > this.id = id;
> > this.price = price;
> > this.shop = shop;
> > this.description = description;
> > }
> >
> > public Item() {}
> > }
> >
> > @XmlRootElement
> > public static class ShoppingList {
> > public String id;
> > public final List<Item> items = new LinkedList<Item>();
> >
> > public ShoppingList(String id) {
> > this();
> > this.id = id;
> > }
> >
> > public ShoppingList() {
> > }
> >
> > public void add(Item i) {
> > this.items.add(i);
> > }
> > }
> >
> >
> > @GET @ProduceMime({"application/xml", "application/json"})
> > public ShoppingList getList() {
> > ShoppingList list = new ShoppingList("123");
> > list.add(new Item("234", 11, "", "Apple"));
> > list.add(new Item("233", 22, "", "Banana"));
> > return list;
> > }
> >
> > Which will return:
> >
> >
> > {"shoppingList":{"id":"123","items":[{"id":"234","price":"11","shop":"","description":"Apple"},{"id":"233","price":"22","shop":"","description":"Banana"}]}}
> >
> > or
> >
> > <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> > <shoppingList>
> > <id>123</id>
> > <items>
> > <id>234</id>
> > <price>11</price>
> > <shop/>
> > <description>Apple</description>
> > </items>
> > <items>
> > <id>233</id>
> > <price>22</price>
> > <shop/>
> > <description>Banana</description>
> > </items>
> > </shoppingList>
> >
> >
> > based on the mime type required.
> >
> > You could easily tweak the JSON "data type" for e.g. price, so that you
> > do not have it represented as String in JSON, but it would require a
> > custom
> > JSONJAXBContext to be defined in your webapp:
> >
> > @Provider
> > public static class JAXBContextResolver implements
> > ContextResolver<JAXBContext> {
> >
> > private JAXBContext context;
> > private Class[] types = {Item.class, ShoppingList.class};
> >
> > public JAXBContextResolver() throws Exception {
> > Map<String, Object> props = new HashMap<String, Object>();
> > props.put(JSONJAXBContext.JSON_NOTATION, "MAPPED");
> > props.put(JSONJAXBContext.JSON_ROOT_UNWRAPPING, Boolean.TRUE);
> > props.put(JSONJAXBContext.JSON_ROOT_UNWRAPPING, Boolean.TRUE);
> > props.put(JSONJAXBContext.JSON_NON_STRINGS, "[\"price\"]");
> > this.context = new JSONJAXBContext(types, props);
> > }
> >
> > public JAXBContext getContext(Class<?> objectType) {
> > return (types[0].equals(objectType)) ? context : null;
> > }
> > }
> >
> >
> > I will probably need to post a new entry to my blog summarizing possible
> > options for JSON/JAXB
> > processing in (current) Jersey.
> >
> > Thanks,
> >
> > ~Jakub
> >
> >
> >
> >
> >
> >
> > >
> > >
> > http://stephan.reposita.org/archives/2008/03/18/experiments-for-nicely-generating-json/
> > >
> > > Additionally I wrote a Message Body Writer which encapsulates the
> > toJson()
> > > call.
> > >
> > > BadgerFish and full object graph dumps in JSON seem to contradict the
> > > purpose
> > > of JSON, a lean, fast to parse and read data format.
> > >
> > > Regards
> > > -stephan
> > >
> > >
> > > On Fri, Apr 4, 2008 at 11:14 AM, Seamus Kerrigan (skerriga) <
> > > skerriga_at_cisco.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > I've been doing some work with Jersey for the past while but yesterday
> > I
> > > > got to try out Jersey 0.7 and it looks as though Badgerfish notation
> > is
> > > > now the default JSON format again? I found that early Jersey versions
> > > > were using Badgerfish by default but 0.6 was using the Mapped notation
> > > > as it's default as outlined in Jakub's blog
> > > > http://blogs.sun.com/japod/entry/better_json_available_in_jersey.
> > > >
> > > > I just have a couple of questions on this JSON formatting:
> > > > - Is Badgerfish likely to be the preferred JSON notation in future
> > > > Jersey releases?
> > > > - Will XmlAttributes be supported in the Mapped/Mapped-Jettison
> > > > formats?
> > > > - The blog outlines a method of changing between JSON formats by
> > > > defining a ContextResolver. Is still this valid in 0.7? I gave this a
> > > > very quick try yesterday but was unsuccessful.
> > > >
> > > > Many thanks,
> > > > Seamus
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > > > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> > > >
> > > >
> > >
> > >
> > > --
> > > Stephan Schmidt :: stephan_at_reposita.org
> > > Reposita Open Source - Monitor your software development
> > > http://www.reposita.org
> > > Blog at http://stephan.reposita.org - No signal. No noise.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> > For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
> >
>
>
> --
> Stephan Schmidt :: stephan_at_reposita.org
> Reposita Open Source - Monitor your software development
> http://www.reposita.org
> Blog at http://stephan.reposita.org - No signal. No noise.