Re: OSGi - deserialization remote invocation strategy

> On Feb 7, 2017, at 8:56 AM, Michał Kłeczek (XPro Sp. z o. o.) > wrote: > > Comments inline > > Niclas Hedhman wrote: >> 4. For Server(osgi)+Client(osgi), number of options goes up. In this space, >> Paremus has a lot of experience, and perhaps willing to share a

Re: OSGi - deserialization remote invocation strategy

Maybe there are some misunderstanding somewhere... see below; On Wed, Feb 8, 2017 at 3:35 AM, Peter wrote: > I'm currently only considering OSGi server -> OSGi client. Mick's investigating all four options. Ok, makes it a lot easier for me to follow. > Not expecting the

Re: Changing TCCL during deserialization

There are lots of places like this, that I have done exactly this to make sure that the visibility of the current class loader is available for a thread which I don’t now the history of. There is nothing that controls how the calling thread might decide (via code, or some other magic) what

Re: OSGi - deserialization remote invocation strategy

Correct in the second instance. Sent from my Samsung device.     Include original message Original message From: Michał Kłeczek Sent: 08/02/2017 09:24:21 am To: dev@river.apache.org Subject: Re: OSGi - deserialization remote invocation strategy So in this case 

Re: OSGi - deserialization remote invocation strategy

So in this case there is no authentication prior to code download? Or the client has to be authenticated before registering a listener. Am I correct? On Tue, 7 Feb 2017 at 22:32, Peter wrote: > Create three bundles, api (if any looks like your using jini platform > class as

Re: OSGi - deserialization remote invocation strategy

No, it's just an example, no such restriction.  But it is restricted to JERI.   RemoteEvents have been extended also in JGDMS to use MarshalledInstance and JErI instead of MarshalledObjects and JRMP.  All methods that rely on MarshalledObject have been deprecated and replacements provided with

Re: OSGi - deserialization remote invocation strategy

Clarification inline. Sent from my Samsung device.     Include original message Original message From: Peter Sent: 08/02/2017 05:35:57 am To: dev@river.apache.org Subject: Re: OSGi - deserialization remote invocation strategy Hi Nic, I'm 

Re: OSGi - deserialization remote invocation strategy

Hmm... I see. So your solution explicitly only handles cases of looking up a service in the ServiceRegistrar. How about smart RemoteEventListeners? They are not published in any lookup service. Thanks, Michal Peter wrote: In the JGDMS fork of River, in addition to Reggie's proxy returing

Re: OSGi - deserialization remote invocation strategy

In the JGDMS fork of River, in addition to Reggie's proxy returing unmarshalled service proxy's from the ServiceRegistrar lookup method, SafeServiceRegistrar provides a lookup method that returns instances of java.lang.reflect.Proxy that implement interfaces to retrieve the service, it's

Re: OSGi - deserialization remote invocation strategy

So I must have misunderstood the part about smart proxies being obtained via "reflection proxies" or MarshalledInstances. What are these "reflection proxies"? Thanks, Michal Peter wrote: No, no bootstrap objects. Cheers, Peter. Sent from my Samsung device. Include original message

Re: OSGi - deserialization remote invocation strategy

Hi Nic, I'm currently only considering OSGi server -> OSGi client.  Mick's investigating all four options. Not expecting the client calling bundle to resolve everything, hence the stack, so we have the full visibility of the bundle of the class that was last resolved, so we can resolve its

Re: OSGi - deserialization remote invocation strategy

No, no bootstrap objects. Cheers, Peter. Sent from my Samsung device.     Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)" Sent: 08/02/2017 12:28:50 am To: dev@river.apache.org Subject: Re: OSGi - deserialization remote

Re: OSGi - deserialization remote invocation strategy

Comments inline Niclas Hedhman wrote: 4. For Server(osgi)+Client(osgi), number of options goes up. In this space, Paremus has a lot of experience, and perhaps willing to share a bit, without compromising the secret sauce? Either way, Michal's talk about "wiring" becomes important and that

Re: Changing TCCL during deserialization

This is fine for me. I am asking not about one interaction where multiple instances of MarshalledInputStreams are used (each with its own TCCL) I am asking about the situation described in another email - that during a deserialization using a single instance of the stream the TCCL is changed.

Re: Changing TCCL during deserialization

I am not sure about “locked”. In my example about ServiceUI, imagine that there is a common behavior that you ServiceUI hosting environment provides to all ServiceUI Components. It can be that there is a button press or something else where an AWTEvent thread is going to take action. It’s

Re: OSGi - deserialization remote invocation strategy

Are you proposing to provide a bootstrap object that will download some meta information prior to class resolution? How does it differ from simply changing annotations to be those "bootstrap objects" instead of Strings? Thanks, Michal Peter wrote: Proposed JERI OSGi class loading strategy

Re: OSGi - deserialization remote invocation strategy

TL;DR 1. It sounds awfully complex, because my gut says that it is not a solvable problem, especially since I don't see 4 distinct cases; Server(osgi)+Client(osgi), Server(osgi)+Client(plain), Server(plain)+Client(osgi) and Server(plain)+Client(plain), where the last one is what we currently have.

OSGi - deserialization remote invocation strategy

Proposed JERI OSGi class loading strategy during deserialization. Record caller context - this is the default bundle at the beginning of the stack. It is obtained by the InvocationHandler on the client side. The InvocationDispatcher on the server side has the calling context of the Remote