Good idea. The server part should probably be split from cayenne-server. Andrus
> On May 5, 2016, at 8:26 PM, Aristedes Maniatis <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>: >>>>> >>>>>> 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 <[email protected]>: >>>>>> >>>>>>> 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
