cayenne-dev mailing list archives

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

-- 
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

Mime
View raw message