Ok, will do,
I am at a conference and not presenting much, so I will have more
time than usual. I'll open a patch as I make progress for others to
look at. I agree with your analysis of Xstream etc, but I am still
wondering if there aren't enough hooks in XStream to get the desired
effect..... so I might see just how ugly it gets to try that as well.
Ian
On 27 Jun 2008, at 23:01, Louis Ryan wrote:
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]
