Perhaps the whole of ROP becomes an optional module? Ari
On 6/05/2016 10:18am, Andrus Adamchik wrote: > It's been a while since I touched the ROP code. Back in the day Java > serialization "kind of worked", but not completely. So you are probably right > that it is not a real option. I am just trying to avoid new dependencies > (even optional) on third-party libs in the Cayenne core. So perhaps we can > simply leave out any "default" serialization and always require an explicit > serialization provider. > > Andrus > >> On May 5, 2016, at 8:12 PM, Aristedes Maniatis <a...@maniatis.org> wrote: >> >> Maybe I'm not understanding correctly, but I don't think Java serialisation >> has been implemented in ROP. The work Dima did was to move away from the >> Hessian servlet stuff for making the HTTP connection, to plain Java with the >> option for plugging in Jetty libraries for HTTP/2. >> >> The work Savva did just now was to use protostuff for serialisation, but I'm >> not sure what's now needed if we wanted plain Java serialisation or whether >> that's even possible without some sort of library to handle an object graph >> with cycles. >> >> Or at least that's my understanding. >> >> Ari >> >> >> On 6/05/2016 9:55am, Andrus Adamchik wrote: >>> Thanks for clarification. I would say use Java serialization as a default, >>> and make it easy to plugin Hessian and Protostuff as separate modules. >>> >>> A. >>> >>>> On May 5, 2016, at 5:39 PM, Savva Kolbachev <s.kolbac...@gmail.com> wrote: >>>> >>>> Hi Andrus, >>>> >>>>> So which one is the default, Hessian or Java? >>>> We still use Hessian for serialization by default >>>> https://github.com/apache/cayenne/blob/master/cayenne-server/src/main/java/org/apache/cayenne/rop/HessianROPSerializationService.java >>>> But we use java.net.URLConnection for establish connection and sending >>>> messages from client to server >>>> https://github.com/apache/cayenne/blob/master/cayenne-client/src/main/java/org/apache/cayenne/rop/http/HttpROPConnector.java >>>> So we have escaped from Hessian only in connectivity layer. >>>> >>>>> I don't have a problem with Protostuff being a recommended default, but >>>> for dependency management purposes I'd rather we split all third-party >>>> integrations in separate modules, and use whatever provider is hooked up in >>>> runtime. Kind of what we do with Joda/Java8 extensions. >>>> I already did it in this way. I created separate module for Protostuff >>>> serialization. >>>> >>>> As Hessian serialization has some troubles with Java8 types and provide >>>> less efficient serialization than Protostuff, I suggest to use Protostuff >>>> as default serialization service or to use Java serialization. So I just >>>> suggest to escape from Hessian :) >>>> >>>> 2016-05-05 19:41 GMT+03:00 Savva Kolbachev <s.kolbac...@gmail.com>: >>>> >>>>> Hi Ari, >>>>> >>>>> Looks like Protostuff works faster than Protobuf in some cases. For >>>>> example Serializers (no shared refs) and Cross Lang Binary Serializers >>>>> sections here http://hperadin.github.io/jvm-serializers-report/report.html >>>>> >>>>> In our case we need to serialize graph of objects (Full Object Graph >>>>> Serializers section in link above). Protobuf can't do it out of the box >>>>> but Protostuff can. In my implementation I use protostuff-graph-runtime >>>>> which generates a schema from objects at runtime and caches it. >>>>> >>>>> Protostuff schema is something like .proto files but in Java: >>>>> http://www.protostuff.io/documentation/schema/ >>>>> Runtime schema: http://www.protostuff.io/documentation/runtime-schema/ >>>>> >>>>> As you could see in benchmarks there is a small difference in efficiency >>>>> between protostuff-graph and protostuff-graph-runtime. The ser/deser >>>>> overhead is related to runtime schema generation. The size penalty is that >>>>> Protostuff adds class name for objects and than uses those for find >>>>> appropriate classes via reflection. >>>>> Hessian also adds fields names so the size of Hessian serialization is >>>>> much bigger. In my small example with selection of 6 objects Hessian >>>>> serialization size is more than 2400 bytes while Protostuff runtime is >>>>> about 800 bytes. >>>>> >>>>> If we don't want to have ser/deser and size overhead we could find a way >>>>> to generate schemas via Velocity. And we should provide schemas for some >>>>> Cayenne classes. But it will require a lot of efforts. >>>>> >>>>> >>>>> 2016-05-05 13:44 GMT+03:00 Aristedes Maniatis <a...@maniatis.org>: >>>>> >>>>>> On 5/05/2016 7:35pm, Savva Kolbachev wrote: >>>>>>> Protostuff (licensed under Apache 2.0 licence) is based on Google's >>>>>>> Protocol-Buffers (Protobuf) but has some optimizations and some cool >>>>>> things >>>>>>> like runtime serialization graph of objects (like Hessian). It also >>>>>> could >>>>>>> generate schema on runtime so we shouldn't define .proto files although >>>>>> it >>>>>>> might increase efficiency. It works faster than Hessian and could handle >>>>>>> Java8 Date and Time types. Here is some benchmarks. Take a look at Full >>>>>>> Object Graph Serializers section. >>>>>>> http://hperadin.github.io/jvm-serializers-report/report.html >>>>>>> https://github.com/eishay/jvm-serializers/wiki >>>>>> >>>>>> According to those benchmarks there appears to be no performance or size >>>>>> penalty to using protostuff over protobuffers. Am I reading that right? >>>>>> >>>>>> I don't really understand... doesn't the serialiser have to construct a >>>>>> .proto definition and then include it in the message? So shouldn't it be >>>>>> faster/smaller to predefine these? >>>>>> >>>>>> If we did, we could create them with velocity in the same way we create >>>>>> Java _superclasses today. Fairly trivial I'm guessing. >>>>>> >>>>>> Ari >>>>>> >>>>>> >>>>>> -- >>>>>> --------------------------> >>>>>> Aristedes Maniatis >>>>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks and Regards >>>>> Savva Kolbachev >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks and Regards >>>> Savva Kolbachev >>> >> >> -- >> --------------------------> >> Aristedes Maniatis >> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > -- --------------------------> Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
