river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <mic...@kleczek.org>
Subject Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Date Mon, 13 Feb 2017 15:42:23 GMT
Both ways have their pros and cons.

But the decision whether there should be one proxy instance or more is 
independent
of the decision on how to resolve the proxy class.
The latter being much more difficult to design properly. So far we have:
1. Use existing PreferredClassLoader infrastructure
This has the issue that you are not reusing any OSGi container class 
loading infrastructure
2. Use OSGi container to install proxy's class bundle - which has other 
problems discusses so far

IMHO there is a third way - but I am still not finished with it :)

Thanks,
Michal

Peter wrote:
> My take is a little different, instead services are discovered and registered, then the
client can utilise them.
>
> The approach you're now suggesting is exactly what Bharath has implented, this is a great
first effort and I believe it can be improved.  It's only worked since River 3.0, I think
we can do much more to support OSGi.
>
> Regards,
>
> Peter.
>
> Sent from my Samsung device.
>   
>    Include original message
> ---- Original message ----
> From: Michał Kłeczek<michal@kleczekorg>
> Sent: 14/02/2017 01:05:54 am
> To: dev@river.apache.org
> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
>
> There are actually two things that we are discussing at the same time:
>
> 1. The need to have an "installer" object and how it should be provided 
> to the client
> 2. The algorithm of class loader resolution in OSGi
>
> These two things are orthogonal to each other and your question is about 
> point 2.
>
> My take on this is that in OSGi you have to delay the unmarshalling 
> decision until a client bundle
> asks for a service.
> Then you simply create a proxy ClassLoader with the delegation parent 
> set to the requesting bundle ClassLoader.
> It means that many instances of the service proxy might be present in 
> the client environment -
> but that is fine since it is no different than deserializing the service 
> proxy in two JVMs.
>
> Thanks,
> Michal
>
> Peter wrote:
>>   service providers for each api version can still be loaded.
>>
>>   But I don't see a way to force all clients to use a single service api version
without a compatibility layer.  Why not just reload the clients so they can use the latest
compatible version of a service?
>>
>>   How does your proposed solution solve this problem?
>>
>>   Regards,
>>
>>   Peter.
>>
>>   Sent from my Samsung device
>>     
>>      Include original message
>>   ---- Original message ----
>>   From: Michał Kłeczek<michal@kleczek.org>
>>   Sent: 14/02/2017 12:39:40 am
>>   To: dev@river.apache.org
>>   Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
>>
>>   But what if the client has MULTIPLE clients - each with its own exact 
>>   API version?
>>
>>   OSGi handles this case just fine with service trackers.
>>
>>   Do you want to give up on this?
>>
>>   Thanks,
>>   Michal
>>
>>   Peter wrote:
>>>     You can however for each service api package version, it's all in the smart
proxy bundle manifest.
>>>
>>>     You are bound by the dependency resolution process, the client can only choose
from compatible versions.  The service has the power to constrain its proxy bundle manifest
if it wishes.
>>>
>>>     Regards,
>>>
>>>     Peter.
>>>
>>>     Sent from my Samsung device
>>>       
>>>        Include original message
>>>     ---- Original message ----
>>>     From: Michał Kłeczek<michal@kleczek.org>
>>>     Sent: 14/02/2017 12:24:58 am
>>>     To: dev@river.apache.org
>>>     Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
>>>
>>>
>>>     Peter wrote:
>>>>       There a multiple remote services, if one client cant obtain a service
because there is also a later version installed then you need a service that doesn't import
the later version.  You can still supply another service to cater.
>>>     This does not scale because you would have to have one service per each 
>>>     service interface version any client might require.
>>>
>>>     No... You have to be able to make this class resolution decision on the 
>>>     client.
>>>     And if the client VM allows to have many class loading context at the 
>>>     same time (as is the case with OSGI) then
>>>     the infrastructure has to take care of this resolution.
>>>
>>>     But you cannot force the service provider to provide separate instance 
>>>     for each case.
>>>
>>>     Thanks,
>>>     Michal
>>>
>>>
>>
>
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message