Mic,
I'm attempting to get my head around your proposal:
In the case of JERI, the InvocationHandler is part of the smart proxy's
serialized state. A number of smart proxy classes will need to be
unmarshalled before the UnmarshallingInvocationHandler is deserialized.
The smart proxy contains a reference to a dynamic proxy (which sun
called the bootstrap proxy) and the dynamic proxy contains a reference
to your UnmarshallingInvocationHandler. This means the smart proxy
must be unmarshalled first.
How do you get access to UnmarshallingInvocationHandler without
unmarshalling the smart proxy first?
More comments inline below.
On 13/02/2017 6:11 PM, Michał Kłeczek wrote:
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)
Agree.
2. You cannot decide upon the bundle chosen by the container to load
the proxy class (the container does the resolution)
Disagree, nothing in the client depends on the proxy bundle, there's no
reason to provision a different version.
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.
Disagree. The proxy bundle contains a manifest with requirements. The
stream has no knowledge of versioning, nor does it need to, there are no
additional constraints. If the service proxy dependencies cannot be
resolved, or it doesn't unmarshall, then it will not be registered with
the OSGi registry in the client, client code will not discover it and
the client will have no knowledge of it's existance except for some logging.
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)
Disagree, I'm not proposing the service have any control over
installation at the client, other than the manifest in the proxy bundle,
nor am I proposing using service attributes, or the use of any existing
ServiceRegistar methods (see SafeServiceRegistrar link posted earlier).
But why not:
public interface RemoteEventProducer {
void registerListener(SmartProxyInstaller installer, byte[]
remoteEventListenerBytes);
}
I guess you could have a service that installs the proxy bundle that
way, but how will you know which ClassLoader the deserialize into at the
client?
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).
I'm proposing to use ServiceDiscoveryManager to discover
SafeServiceRegistrar's, then look up matching services, receive dynamic
proxy's from each of the matching services (using input validating
deserialization, a security measure) that allow the ProxyPreparer to
authenticate each service, get attributes, perform local logical
attribute comparisons, get the codebase URL string, certificate signers,
grant permissions, then finally provision the codebase and finally
retrieve the smart proxy, directly from the dynamic proxy.
Now we could put your UnmarshallingInvocationHandler into the dynamic
proxy, but then we might be installing a bundle we decide we don't want
after logical comparisons of attributes. The InvocationHandler's intent
is to marshall object arguments, when methods are invocated on the
dynamic proxy. The InvocationDispatcher unmarshalls the arguments at
the remote end and invokes the methods on the Remote object.
So I'm proposing to write some code that performs service discovery
using the above and registers the successfully matched services with the
local OSGi service registry. So the client needn't be concerned with
the time taken to remotely discover and provision a service, all that
happens in the background until the services can be made available in
the OSGi service registry for the client to utilise.
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???
That's not what I'm proposing, see above.
Cheers,
Peter.
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?