To be fair, my position changed somewhat after Nic's email and some
further research, it may of course develop further with understanding
and experimentation.
Cheers,
Peter.
On 13/02/2017 7:52 PM, Peter wrote:
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?
