FYI in case you didn't know; Jackson ObjectMapper takes a POJO structure and creates a (for instance) JSON document, or the other way around. It is not meant for "any object to binary and back". My point was, Java Serialization (and by extension JERI) has a scope that is possibly wrongly defined in the first place. More constraints back then might have been a good thing...
On Sat, Feb 4, 2017 at 12:36 PM, Peter <j...@zeus.net.au> wrote: > On 4/02/2017 12:43 PM, Niclas Hedhman wrote: > >> On Fri, Feb 3, 2017 at 12:23 PM, Peter<j...@zeus.net.au> wrote: >> >> No serialization or Remote method invocation framework currently supports >>> OSGi very well, one that works well and can provide security might gain a >>> lot of new interest from that user base. >>> >> >> What do you mean by this? Jackson's ObjectMapper doesn't have problems on >> OSGi. You are formulating the problem wrongly, and if formulated >> correctly, >> perhaps one realizes why Java Serialization fell out of fashion rather >> quickly 10-12 years ago, when people realized that code mobility (as done >> in Java serialization/RMI) caused a lot of problems. >> > > Hmm, I didn't know that, sounds like an option for JERI. > > > IMHO, RMI/Serialization's design is flawed. Mixing too many concerns in the >> same abstraction; sandboxing w/ integration , code mobility, class >> resolution, versioning and deserialization, with very little hooks to >> cusomize any or all of these aspects. And these aspects should not have >> been wrapped into one monolith. >> >> Further, I think the only "sane" approach in a OSGi environment is to >> create a new bundle for the Remote environment, all codebases not part of >> the API goes into that bundle and that the API is required to be present >> in >> the OSGi environment a priori. I.e. treat the Remote objects in OSGi as it >> is treated in plain Java; one classloader, one chunk, sort out its own >> serialization woes. Likewise for the server; treat it as ordinary RMI, >> without any mumbo-jambo OSGi stuff to be figured out at a non-OSGi-running >> JVM. An important difference is that in OSGi, the BundleClassLoader is not >> (required to be) a URLClassLoader, so the Java serialization's auto >> annotation of globally reachable URLs won't work, and one need to rely on >> java.rmi.server.codebase property, but a bundle could watch for loaded >> bundles and build that up for URLs that can be resolved globally. >> >> >> Cheers >> > > -- Niclas Hedhman, Software Developer http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
