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<mic...@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<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
