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]
