Ok, I've looked at this some more and I dont think we should use Enunciate, XStream, Jettison or JAXB for a couple of reasons...
*1. The JSON format in the spec is not compatible with a format that can be parsed by any of these tools. These tools really only support one of two formats* a. http://badgerfish.ning.com/ - A canonical mapping of XML documents which is overkill for our needs b. A type annotated model which expects there to be a type annotation on an object E.g. For an activity { "activity" : { "id" : 1, "title" : "my activity" }} this is different from what is documented in the spec where the type is inferred from the endpoint on which the request is received so it becomes simply { "id" : 1, "title" : "my activity" } this difference becomes even more pronounced on collections of typed objects. A type annotated model for an activity with media items would look like { "activity" : { "id" : 1, "title" : "my activity", "mediaItems" : [ { "mediaItem" : { "mimeType" : "image/jpeg", "url" : "someurl" }}]}} as per the spec this would look like { "id" : 1, "title" : "my activity", "mediaItems" : [{ "mimeType" : "image/jpeg", "url" : "someurl" }]} where the type is inferred through owned objects. The fact that a fully type-inferred model isnt supported by any of these tools is a little disappointing and may impact adoption of the JSON API in Java land *2. None of these tools offer any performance advantage over parsing using a standard JSON library* Most of the tools listed above use Jettison to create a StaX interface over JSON. It does this using the JSON.org library so there isnt really any stream-parsing going on here so no much performance advantage... @Ian - I think you should continue what youre doing with json-lib. Im happy to help out with what you've done so far if you have something in a patchable state On Thu, Jun 26, 2008 at 6:10 AM, Ian Boston <[EMAIL PROTECTED]> wrote: > Agreed, the json-xml serializer (jettison) is as solid, well supported and > reportedly well written Stax parser (one of my team has been using it > heavily). being stax its going to be good a streaming with low GC impact. > > What is less clear (to me at least) at the moment, is how the beans get > generated. We have a service API and so the Model impls eg PersonImpl > objects are really just implementations of API that is mentioned in the > service APIs. For the JSON -> Java serialization to work, the impl beans > need to be instanced without mentioning the concrete implementations above > the API. > > Doing this with Guice is easy, as the Service (eg PersonService) > implementation module will define what the concrete implementations of the > model are, so of Xstream can use an injector to construct the request bean > tree, then it only need to talk about interfaces. It looks like a generic > GuiceConverter (implementing http:// > xstream.codehaus.org/javadoc/com/thoughtworks/xstream/converters/Converter.html) > might be capable of performing this task. > > So, I think both approaches are worth doing, and I have a feeling that > Xstream perform better on a number of fronts.... but thats just a feeling. > > Ian > > > On 26 Jun 2008, at 02:14, Robert Evans wrote: > > We used XStream in a previous company for serializing very large amounts >> of >> java call traces, and it worked very well. >> >> Bob >> >> On Wed, Jun 25, 2008 at 4:35 PM, Ian Boston <[EMAIL PROTECTED]> wrote: >> >> >>> >>> Some comments also inline: >>> >>> >>> This bit looks like it works OOTB, >>> >>> public String convertToString(Object pojo) { >>> JSONObject jsonObject = JSONObject.fromObject(pojo); >>> return jsonObject.toString(); >>> } >>> >>> and >>> >>> I am still working on this, although I think that the jsonConfig or the >>> Guice module will need a bit more here. >>> The Impl's need to be bound to the interfaces in the injector, and there >>> might need to be a field translator in the config. >>> >>> public <T> T convertToObject(String string, final Class<T> rootBeanClass) >>> { >>> JSONObject jsonObject = JSONObject.fromObject(string); >>> JsonConfig jsonConfig = new JsonConfig(); >>> >>> // enable Guice >>> jsonConfig.setNewBeanInstanceStrategy(new NewBeanInstanceStrategy(){ >>> >>> >>> >>> @SuppressWarnings("unchecked") >>> @Override >>> public Object newInstance(Class beanClass, JSONObject jsonObject) >>> throws InstantiationException, IllegalAccessException, >>> SecurityException, NoSuchMethodException, >>> InvocationTargetException { >>> if ( beanClass == null ) { >>> beanClass = rootBeanClass; >>> } >>> Object o = >>> BeanJsonLibConverter.this.injector.getInstance(beanClass); >>> return o; >>> } >>> >>> }); >>> >>> // load the JSON >>> T rootObject = injector.getInstance(rootBeanClass); >>> Object o = JSONObject.toBean(jsonObject,rootObject,jsonConfig); >>> return (T) o; >>> } >>> >>> More comments inline: >>> >>> >>> On 26 Jun 2008, at 00:14, Louis Ryan wrote: >>> >>> Notes inlined.... >>> >>>> >>>> On Wed, Jun 25, 2008 at 3:47 PM, Ian Boston <[EMAIL PROTECTED]> wrote: >>>> >>>> Ryan, >>>> >>>>> I have been looking at json-lib over the past few days, and have the >>>>> java -> json serialization all working, and some of the json -> java >>>>> serialization working (as BeanJsonLibConverter) with the classes >>>>> coming from a guice injector (so that the calls can bind to interfaces >>>>> rather than concrete classes). I was also going to look at Xstream >>>>> because I had heard it was good.... comparitive evidence being better >>>>> than guesswork.......but I will leave XStream if you are going to look >>>>> at it. >>>>> >>>>> >>>> >>>> I guess the answer here will be whichever one we like best. Im hopeful >>>> that >>>> XStream will be a very small amount of code but I'Inm just starting. It >>>> does >>>> have the advantage of creating an idiomatic non-ATOM XML API that >>>> matches >>>> the JSON one basically for free if we want it. If you have a patch you >>>> want >>>> me to look at send it along. >>>> >>>> >>>> >>>> >>>> >>>>> One thing that this has lead me to realize is that whatever the >>>>> serialization mechanism is, we need to have some test cases that can >>>>> validate as much of the API as possible without relying on hand coding >>>>> the test cases and risking transcription errors. I dont know if it >>>>> will work, but I am loading the opesocial-reference/features.xml into >>>>> a Rhino context and extracting the json definition direct from the js >>>>> api. Hopefully this will mean that the wire protocol stays in step >>>>> with the js api definition, and the unit tests wont rely on >>>>> hand-recoding each time the API is revision(ed). >>>>> >>>>> Is this a dumb idea ? >>>>> >>>>> >>>> >>>> An interesting idea for sure but this may end up being tricky, how are >>>> you >>>> extracting the JSON format from the JS API as it isnt something which is >>>> explicitly 'declared' in that code but rather just consumed. >>>> >>>> >>> >>> 2 approaches (experiments), but I am not certain if they will work. >>> >>> I can drill into the attributes defining the JSON fields and validate >>> that >>> the JSON has the required structure. >>> >>> eg opensocial.Person.Fields contains the names of the JSON fields for >>> Person, it may need knowledge that person has fields containing other >>> fields >>> eg addresses. >>> >>> I am not expecting this to give a complete test, but it might validate >>> some >>> of the structure of the message. >>> >>> Or (if I can find the right place to do it) I can parse the JSON inside >>> Rhino, and then look in via the API access methods that use the Fields... >>> I >>> remember seeing a generic getter somewhere at one point when scanning the >>> js. >>> >>> >>> >>> >>> >>>> >>>> >>>>> and is completing a json-lib serializer a waste of effort ? >>>>> >>>>> Ian (not wanting to duplicate effort unnecessarily) >>>>> >>>>> 2008/6/25 Louis Ryan <[EMAIL PROTECTED]>: >>>>> >>>>> Ok now that Im back to working on the RESTful side of things I took a >>>>>> >>>>>> look >>>>> >>>>> at Pauls suggestion to use XStream as the serialization mechanism at >>>>>> >>>>>> least >>>>> >>>>> for JSON handling and I think it has a lot of merit. Im going to do >>>>>> some >>>>>> prototyping in Shindig with this. >>>>>> >>>>>> I've been catching up on the code since Im back from vacation so Ill >>>>>> >>>>>> start >>>>> >>>>> to make contributions in this area mostly focused on the JSON APIs >>>>>> >>>>>> initially >>>>> >>>>> as this seems to be where the most interest is and where the >>>>>> >>>>>> implementation >>>>> >>>>> path is clearest. My goal will be to have the Shindig JSON >>>>>> implementation >>>>>> working end-to-end in Orkut in large part to provide feedback on the >>>>>> API >>>>>> stack based on a working implementation (I hate working in a bubble!) >>>>>> >>>>>> >>>>>> On Tue, Jun 10, 2008 at 3:11 PM, Paul Lindner <[EMAIL PROTECTED]> >>>>>> wrote: >>>>>> >>>>>> It's not enunciate that provides the magic, it just uses xstream to >>>>>> do >>>>>> >>>>>>> >>>>>>> the >>>>>> >>>>> >>>>> dirty work: >>>>>> >>>>>>> >>>>>>> http://xstream.codehaus.org/json-tutorial.html >>>>>>> >>>>>>> You can either use jettison or your own driver. >>>>>>> >>>>>>> For the jaxb mappings you can add something like this to the top of >>>>>>> the >>>>>>> model classes: >>>>>>> @XmlRootElement( >>>>>>> name = "person", >>>>>>> namespace = "http://opensocial.org/2008/opensocial"; >>>>>>> ) >>>>>>> >>>>>>> And add >>>>>>> >>>>>>> @XmlElement above each of the getters.. >>>>>>> >>>>>>> For enums you need something like this: >>>>>>> @XmlJavaTypeAdapter(Enum.DrinkerAdapter.class) >>>>>>> >>>>>>> and a corresponding adapter. >>>>>>> >>>>>>> sample here: >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://www.hi5networks.com/platform/browser/shindig/trunk/java/ >>>>>>> >>>>>> >>>>> social-api/src/main/java/org/apache/shindig/social/opensocial/model/Person.java >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> On Jun 10, 2008, at 2:57 PM, Cassie wrote: >>>>>>> >>>>>>> Hmm.. I just worry that it would turn out like abdera... not >>>>>>> providing >>>>>>> >>>>>>> enough benefit for the learning curve. I mean, the restful json spec >>>>>>>> is >>>>>>>> really very simple, I'm hoping we can just whip it up :) >>>>>>>> >>>>>>>> I could be convinced otherwise though - do you have any code you can >>>>>>>> >>>>>>>> share >>>>>>> >>>>>> >>>>> that uses enunciate? >>>>>> >>>>>>> >>>>>>>> - Cassie >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jun 10, 2008 at 2:52 PM, Paul Lindner <[EMAIL PROTECTED]> >>>>>>>> >>>>>>>> wrote: >>>>>>> >>>>>> >>>>> >>>>>> If you're going down this route you might want to consider using >>>>>>>> JAXB >>>>>>>> >>>>>>>> annotations and a custom json converter. >>>>>>>>> >>>>>>>>> This type of situation is working quite well for us in the >>>>>>>>> Enunicate >>>>>>>>> toolkit and is already implemented there. In fact we've added JAXB >>>>>>>>> annotations to our internal shindig repo and it's worked out >>>>>>>>> really, >>>>>>>>> really >>>>>>>>> well. >>>>>>>>> >>>>>>>>> As far as atom goes.. I have a set of classes that implement Atom >>>>>>>>> in >>>>>>>>> JAXB >>>>>>>>> that I'd be happy to contribute. >>>>>>>>> >>>>>>>>> Check out http://enunciate.codehaus.org/ >>>>>>>>> >>>>>>>>> Ryan, can you offer your thoughts? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Jun 10, 2008, at 2:44 PM, Cassie wrote: >>>>>>>>> >>>>>>>>> We tried to use abdera to implement the opensocial json restful >>>>>>>>> format >>>>>>>>> >>>>>>>>> within Shindig.. and it didn't work out very well. The code is >>>>>>>>> >>>>>>>>>> >>>>>>>>>> clunky, >>>>>>>>> >>>>>>>> >>>>> overly complicated for simple json and is hard to come up to speed >>>>>> >>>>>>> >>>>>>>>>> on. >>>>>>>>> >>>>>>>> >>>>> >>>>>> So... I am going to try an alternate implementation based on the >>>>>>>>>> existing >>>>>>>>>> older json wire format code. I was going to start coding something >>>>>>>>>> in >>>>>>>>>> >>>>>>>>>> a >>>>>>>>> >>>>>>>> >>>>> separate dir so that none of the current code is disturbed. >>>>>> >>>>>>> >>>>>>>>>> Hopefully, >>>>>>>>> >>>>>>>> >>>>> in >>>>>> >>>>>>> the next couple days we will have a cleaner impl of the restful json >>>>>>>>>> that >>>>>>>>>> is >>>>>>>>>> 90% the same as all of the current social code. (this means less >>>>>>>>>> migration >>>>>>>>>> for current social code users too, yea!) >>>>>>>>>> >>>>>>>>>> And as for atom... well, we can figure that out later :) >>>>>>>>>> >>>>>>>>>> Please let me know if you have any huge objections to this. >>>>>>>>>> And of course, if it turns out to be worse than the abdera impl.. >>>>>>>>>> we >>>>>>>>>> >>>>>>>>>> can >>>>>>>>> >>>>>>>> >>>>> always go back. >>>>>> >>>>>>> >>>>>>>>>> - Cassie >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Paul Lindner >>>>>>>>>> >>>>>>>>> [EMAIL PROTECTED] >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Paul Lindner >>>>>>>>> >>>>>>>> [EMAIL PROTECTED] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>> >
