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]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>
