Thanks Nic,
JERI shouldn't be considered as being limited to or dependant on Java
Serialization, it's only a transport layer, anything that can write to
an OutputStream and read from an InputStream will do.
The JSON document could be compressed and sent as bytes, or UTF strings
sent as bytes.
See the interfaces InboundRequest and OutboundRequest.
Cheers,
Peter.
On 4/02/2017 3:35 PM, Niclas Hedhman wrote:
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
