Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
Subject: Re: [jira] [Commented] (CAY-2038) Hessian serialization error when
 using JSR-310 Date types with ROP
From: Andrus Adamchik <andrus@objectstyle.org>
In-Reply-To: <5662EF24.1000902@maniatis.org>
Date: Mon, 7 Dec 2015 09:37:45 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BAD61AC-67F2-4D3B-9E2E-F874C35FF435@objectstyle.org>
References: <JIRA.12912479.1447337958000@Atlassian.JIRA>
 <JIRA.12912479.1447337958655@arcas>
 <JIRA.12912479.1447337958000.169671.1448328131223@Atlassian.JIRA>
 <B5C8D7AE-4416-4A1B-AC20-587A05D73A38@objectstyle.org>
 <5662EF24.1000902@maniatis.org>
To: dev@cayenne.apache.org

> 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.=20

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

> 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:
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> 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.
>=20
> I'd like to make some time for my team to have the freedom to explore =
some of these ideas. Maybe after Christmas...
>=20
> Ari
>=20
>=20
> [1] https://github.com/protostuff/protostuff
>=20
>=20
> On 5/12/2015 7:33pm, Andrus Adamchik wrote:
>> Yeah, Hessian looks dead.=20
>>=20
>> Protobuf is widely used as a wire protocol for NoSQL databases, etc. =
=46rom 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.=20
>>=20
>> 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.
>>=20
>> 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.=20=

>>=20
>> Andrus
>>=20
>>=20
>>> On Nov 24, 2015, at 4:22 AM, Ari Maniatis (JIRA) <jira@apache.org> =
wrote:
>>>=20
>>>=20
>>>   [ =
https://issues.apache.org/jira/browse/CAY-2038?page=3Dcom.atlassian.jira.p=
lugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D15023542#c=
omment-15023542 ]=20
>>>=20
>>> Ari Maniatis commented on CAY-2038:
>>> -----------------------------------
>>>=20
>>> 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:
>>>=20
>>> 1. Fix Hessian and fork it
>>> 2. Move to something else
>>>=20
>>> 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.
>>>=20
>>> I think our criteria should be:
>>>=20
>>> * 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)
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>>=20
>>> Thoughts?
>>>=20
>>> [1] =
http://maillist.caucho.com/pipermail/hessian-interest/2014-June/thread.htm=
l#1150
>>>=20
>>>> Hessian serialization error when using JSR-310 Date types with ROP
>>>> ------------------------------------------------------------------
>>>>=20
>>>>               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
>>>>=20
>>>>=20
>>>> Getting StackOverflowError during hessian serialization when =
querying for entities which have LocalDate, LocalDateTime or LocaTime =
type properties.
>>>=20
>>>=20
>>>=20
>>> --
>>> This message was sent by Atlassian JIRA
>>> (v6.3.4#6332)
>>=20
>=20
> --=20
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A