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