Keep in mind that standard java serialization recently was revealed to have serious security issues.
https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread I wanted a quick way to send java data over the network last weekend and I came across this BSD licensed project: https://github.com/EsotericSoftware/kryonet It uses kryo as the serialization framework: https://github.com/EsotericSoftware/kryo For the simplistic things I wanted to do so far, it's been trivial to use. Unfortunately, I didn't save the link which compared a bunch of these frameworks and eventually led me to kryonet/kryo. But I did just find this page which benchmarks a large number of them, including kryo/hessian/protobuf. It might be helpful in determining what is out there. https://github.com/eishay/jvm-serializers/wiki On Sat, Dec 5, 2015 at 9:05 AM, Aristedes Maniatis <a...@maniatis.org> wrote: > 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
