Comments inline.
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?
No no - I am saying about wrapping the smart proxy inside another
object. It can be either a dynamic proxy, or simply an object that
implements "readResolve" returning the unmarshalled smart proxy.
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.
This is totally backwards.
That way no client is able to find any service because there is a
chicken and egg problem - we do not know the proxy interfaces until the
proxy's bundle is resolved.
Understand that when you place a bundle identifier in the stream - it is
equivalent to specifying a Require-Bundle constraint - nothing more
nothing less.
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).
If you think about it from the higher architectural view - there is no
difference. It does not really matter what steps are made - important
thing is that:
a) you have a special object used to download code - this object is
supposed to be of a class installed locally in advance
b) the above object is used to create a ClassLoader that you will use it
load the actual deserialized object's class
It does not matter where the first object is taken from - be it
"SafeServiceRegistrar", the stream itself, a JavaSpace or the Moon.
Thanks,
Michal
