cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [jira] [Commented] (CAY-2038) Hessian serialization error when using JSR-310 Date types with ROP
Date Sat, 05 Dec 2015 08:33:30 GMT
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) <jira@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)


Mime
View raw message