N.B. Thanks for discussing, I think all these questions are helping people understand the proposal better and clearing up confusion. If it stands up to scruitiny, then it also provides more confidence in the solution.
Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Peter <j...@zeus.net.au> Sent: 14/02/2017 12:33:54 am To: dev@river.apache.org <dev@river.apache.org> Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy 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 <mic...@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
