Even better I think is to make the serialisation layer pluggable. Dima and I were discussing that briefly, but a bit of work is needed to make that happen.
Personally I like protobuf and the schema files (there are files called 'proto') which carry the definition of the object fields are very simple. I think they could be easily generated by cgen and velocity. They are no more onerous than our existing "client entities" on the server. There is also a schema-less clone of protobuf called protostuff [1] and there is no reason that json or xml couldn't be pluggable options. The latest protobuf now in beta even has the ability to dump the entire communication channel into json. That seems like a really cool way to debug things. At the same time, we are looking at replacing the Java http client libraries used for ROP with Apache commons http implementation, because the default Java ones don't properly handle keep-alive over SSL. It would make a lot of sense to have clear separation/injection between ORM, serialisation and transport. Right now they touch each other too much. I'd like to make some time for my team to have the freedom to explore some of these ideas. Maybe after Christmas... Ari [1] https://github.com/protostuff/protostuff On 5/12/2015 7:33pm, Andrus Adamchik wrote: > Yeah, Hessian looks dead. > > Protobuf is widely used as a wire protocol for NoSQL databases, etc. From > that perspective it is a very good candidate. Though IIRC it requires some > form of a "schema", while ROP relies on a generic serialization approach. > > My earlier ideas of using LinkRest for ROP are probably not (yet?) practical. > LinkRest stays away from generic data operations (in other words, each LR > operation is rooted in some entity). Though we can create an extension that > changes this assumption, and still use the underlying machinery. > > I think the cheapest option for us is to use Java built-in serialization. It > kind of works already with a few quirks. The downside is that the client must > be Java, but this is a reality of ROP anyways. > > Andrus > > >> On Nov 24, 2015, at 4:22 AM, Ari Maniatis (JIRA) <j...@apache.org> wrote: >> >> >> [ >> https://issues.apache.org/jira/browse/CAY-2038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15023542#comment-15023542 >> ] >> >> Ari Maniatis commented on CAY-2038: >> ----------------------------------- >> >> I found an old post on the Hessian list [1], but with no reply. Looks like >> we should consider Hessian effectively abandoned. To fix this and also >> review the library for serialisation security issues (like was found for the >> Java serialisation) we should decide whether we: >> >> 1. Fix Hessian and fork it >> 2. Move to something else >> >> If we move, some options are here: >> http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html >> Also, there is a Google library >> https://developers.google.com/protocol-buffers/ which is interesting and >> licensed with something that looks like a simple BSD license. >> >> I think our criteria should be: >> >> * not XML (to keep the size of the data to a minimum) >> * over HTTP (that's a significant benefit of the current approach since it >> makes things like SSL easy) >> >> Against some tests https://github.com/eishay/jvm-serializers/wiki >> protocol-buffers look to be smaller/faster than Hessian. And the community >> appears to be alive and well: >> https://groups.google.com/forum/#!forum/protobuf However, it appears that >> protocol-buffers require a .proto file to define the object serialisation so >> either that would need to be generated dynamically at runtime or by the cgen >> velocity scripts. I think. >> >> If we stay, one of the bigger problems is that Caucho have historically >> rarely accepted patches or responded to community discussions. There is no >> bug tracker, no official separate source control. Just a module buried >> inside Resin which doesn't get touched much and only sporadically is >> released to maven. Having said that, perhaps the patches are simple. >> >> Someone talks about using protocol-buffers with Spring HTTP invoker: >> http://www.eishay.com/2008/11/using-spring-rpc-for-protobuf-transport.html >> but I'm not deep enough into this yet to understand the benefits. >> >> >> Thoughts? >> >> [1] >> http://maillist.caucho.com/pipermail/hessian-interest/2014-June/thread.html#1150 >> >>> Hessian serialization error when using JSR-310 Date types with ROP >>> ------------------------------------------------------------------ >>> >>> Key: CAY-2038 >>> URL: https://issues.apache.org/jira/browse/CAY-2038 >>> Project: Cayenne >>> Issue Type: Bug >>> Components: ROP >>> Affects Versions: 4.0.M3 >>> Reporter: Dzmitry Kazimirchyk >>> Assignee: Savva Kolbachev >>> Attachments: jsr310-dates-rop.patch >>> >>> >>> Getting StackOverflowError during hessian serialization when querying for >>> entities which have LocalDate, LocalDateTime or LocaTime type properties. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.3.4#6332) > -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
