If your requirement is to marshal JPA entities, Seam Remoting does that now using XML. AFAIK the Seam developers chose XML over JSON because JSON doesn't handle arbitrary graphs of objects very well.
If your requirement is to use JSON, then you'd have to build your own marshalling for Seam Remoting. IMO that would be a lot of work for something that isn't as good, but suit yourself.
We use Seam Remoting extensively, and we use it along side Prototype and several other JS libraries with no issues. Entities and transfer objects get transferred to and from the browser very easily.
I believe extjs accepts xml too, I guess I can use that. Could you pl explain this --
JSON doesn't handle arbitrary graphs of objects very well
Since the server stste is
cut offonce entities are marshaled, do Seam Conversations hold any good?
And what do I need to do to integrate extjs with Seam? Any blogs, examples, appreciated!
I do intend to support JSON in Seam Remoting eventually, as there's a lot of JS libraries/widget sets that are designed to consume JSON natively. The reason that I went with an XML-RPC style protocol in the first place is because JSON, being a
flatrendition of an object graph does not faithfully reproduce recursive relationships between objects.
Here's a real world example - say you have a Customer entity with a mainAddress property - each Address also has a reference back to Customer. In unmarshalling a Customer instance such as this, I believe that JSON would create 3 objects - one Customer (the root of the graph), one Address (the mainAddress property of the root Customer) and another Customer (which the Address references).
With the XML-based protocol, Seam Remoting will create just 2 objects - the root Customer, and one Address object for its mainAddress property. The reference between Address and its Customer (the root Customer) will be correctly restored.