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 Mon, 07 Dec 2015 06:37:45 GMT
> 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. 

We'll also need to map to protobuf all current and future Cayenne queries, metadata objects
and commit operations. 

> They are no more onerous than our existing "client entities" on the server.

But changing serializer won't help to get rid of server-side dependency on client entities,
or will it?

Andrus



> On Dec 5, 2015, at 5:05 PM, Aristedes Maniatis <ari@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) <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