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.
Resolution is performed after remote discovery, SafeServiceRegistrar lookup and authentication but prior to deserialization of the smart proxy. It can take as long as it needs, its a background task. The ClassLoader of the provisioned resolved and started smart proxy bundle is used to deserialize the proxy. Regards, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz> Sent: 13/02/2017 11:59:34 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy Comments inline. Peter wrote: N.B Can't see any chicken egg problem. If service doesn't resolve to same service api as client, then it isn't compatible. The client isn't interested in incompatible services, only those that are compatible This is just an artifact of the dependency resolution process. But when do you perform resolution? Lets say you have two client bundles: Client1 is resolved to depend on package a.b.c ver 1.1.3 from bundle a.b.c 1.1.3 Client2 is resolved to depend on package a.b.c ver 1.2.0 from bundle a.b.c 1.2.0 Your service supports both clients. How do you resolve it so that it can be linked with both clients? The answer is - you can not. You must create two different instances of the service proxy each one instantiated from a class loaded in a different context. But you cannot decide upon this context in advance!!! You have to know which client you are serving. No bundle indentifiers are necesary in the stream, the smart proxy ClassLoader decides visibility and delegation, not RMIClassLoader. But what ClassLoader is used to load the smart proxy??? You're attempting to do too many things with one class / object, there's a risk that this very powerful class could be leveraged by an attacker, best to break up the functionality. Why do you think that it is handled by one class/object??? Also ServiceDiscoveryManager handles a lot of scenarios that occur with remote services, your class wont, there are thousands of lines of code. Have a look at SDM in JGDMS. Sorry for sarcasm, but... This is one class/object doing so many things... Thanks, Michal
