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]
