We are talking about the same thing.
We are turning circles, Peter - all of this has been already discussed.
1. Yes - you need to resolve bundles in advance (in OSGi it is not
possible to do otherwise anyway)
2. You cannot decide upon the bundle chosen by the container to load the
proxy class (the container does the resolution)
3. The runtime graph of object places additional constraints on the
bundle resolution process (to what is specified in bundles' manifests).
Since you do not have any way to pass these additional constraints to
the container - the case is lost.
Additionally - to explain what I've said before about wrong level of
abstraction:
Your general idea is very similar to mine: have a special object (let's
call it installer) that will install software prior to proxy unmarshalling.
1. For some reason unclear to me you want to constrain the way how this
"installer object" is passed only via the route of ServiceRegistrar (as
attributes)
But why not:
public interface RemoteEventProducer {
void registerListener(SmartProxyInstaller installer, byte[]
remoteEventListenerBytes);
}
I cannot see a difference at all and this is why I say that mixing
ServiceRegistrar and ServiceDiscoveryManager
into it is really mixing levels of abstraction (and does not add
anything to the solution).
2. If you allow to pass "installer" to unmarshall proxies - then the
next question is - why do you require doing it explicitly in the
application code???
THIS is really mixing levels of abstraction. A programmer expects a
natural programming model (and will not buy into Jini if it does not
offer such):
registerListener(RemoteEventListener listener);
without any additional complexities that should be solved by the
infrastructure code.
3. But the above is easy to solve:
class UnmarshallingInvocationHandler implements InvocationHandler {
private Object unmarshalledProxy;
private SmartProxyInstaller installer;
writeObject(...) { write out installer and proxy bytes }
readObject(...) {read installer then bytes and then unmarshall the proxy}
}
4. But then the next question is why not put it in the object stream
implementation itself???
Thanks,
Michal
Peter wrote:
Also see the OSGi Enterprise specification, v6, Chapter 136, page 691,
there's some discussion about the NP-complete nature of dependency
resolution there as well.
https://www.osgi.org/developer/downloads/release-6/release-6-download/
On 13/02/2017 5:19 PM, Peter wrote:
OSGi Dependency resolution is.
http://underlap.blogspot.com.au/2010/02/osgi-resolution-is-np-complete-so-what.html
Which means if we want to support an OSGi environment properly, we
may need some time to resolve the dependencies for a smart proxy,
before deserializing the proxy, rather than downloading the proxy
dynamically during unmarshalling, it's better to delay unmarshalling
until the dependencies are resolved, so the client isn't impacted by
delays.
Cheers,
Peter.
On 13/02/2017 4:50 PM, Michał Kłeczek wrote:
Sorry, NP Completness of what?
I have been the first to mention NP hardness of constraint
satisfaction problem
but I am not sure if this is what you are asking about.
Thanks,
Michal
Patricia Shanahan wrote:
Are you literally claiming NP Completeness, or just using that as
an analogy for really, really difficult?
