Re: OSGi

There is a lot of code in the base implementation of the endpoints. It’s quite deep to “replace”. But, it is replaceable. I’ve sometimes started to create various types of protocols instead of Marshalled data. But, practically, I’ve not decided to do that. There are other technologies like

Re: OSGi

I know that. And while it is better than Java RMI for several reasons (extensibility being one of them) - it is still not perfect: 1) It is inherently blocking 2) Does not support data streaming (in general you need a separate comm channel for this) 3) invocation layer depends on particular

Re: OSGi

FYI. JERI != Java RMI. There's no reason these layers couldn't be provided as OSGi services and selected from the service registry either. Cheers, Peter. Protocol Stack The Jini ERI architecture has a protocol stack with three layers as shown in the following table, with interfaces

Re: OSGi

Are you opposing the whole idea of sending data and code (or instructions how to download it) bundled together? (the spec) Or just the way how it is done in Java today. (the impl) If it is the first - we are in an absolute disagreement. If the second - I agree wholeheartedly. Thanks, Michal

Re: OSGi

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

Re: OSGi

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

Re: OSGi

On 4/02/2017 12:43 PM, Niclas Hedhman wrote: On Fri, Feb 3, 2017 at 12:23 PM, Peter 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

Re: OSGi

On Fri, Feb 3, 2017 at 12:23 PM, Peter 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?

Re: OSGi

I meant RMIClassLoaderSPI below. And note that this mechanism is currently a VM Wide implementation detail, instead of being a service proxy specific mechanism. That’s where we need to be able to allow for something specific to plugin for a specific service to use a specific platform for

Re: OSGi

I was merely speaking of a ClassLoader which might composite several ClassLoaders using something like the codebase annotation. If we want to make it possible to load service proxies and serviceUI codebases from “anywhere” in Jini, we should be prepared to utilize whatever “compositing”