Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Date: Thu, 23 Feb 2017 15:26:15 +1000 (AEST)
From: Peter <jini@zeus.net.au>
Subject: OSGi Bundles for services
To: "dev@river.apache.org" <dev@river.apache.org>
Message-ID: <224914786d291f90bd492a0003282852@org.tizen.email>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1424321324-1487827575=:1321"
archived-at: Thu, 23 Feb 2017 05:26:32 -0000

--8323328-1424321324-1487827575=:1321
Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="8323328-1289003160-1487827575=:1321"

--8323328-1289003160-1487827575=:1321
Content-Type: TEXT/plain; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

I've attached some ASCII of the relationship between server and client jvm =
bundles.=0A=0AThe ClassLoader at the server is set using the invocation lay=
er factory (a configuration item).=0A=0AThe client ClassLoader is determine=
d during delayed unmarshalling and smart proxy bundle provisioning.=0A=0ATh=
is ensures that deserialization at each endpoint has a compatible view of c=
lasses (as recently discussed on osgi-dev).=0A=0AIt's important at this tim=
e to distinguish between remote objects and remote services, registered wit=
h a lookup service.=0A=0AA remote service must have a proxy bundle for OSGi=
 =C2=A0The proxy bundle manifest determines requirements and wiring to pac=
kage import versions. =C2=A0This includes dynamic proxy based services.=0A=
=0AFor arguments sake, a remote object becomes a remote service when it is =
registered with a lookup service.=0A=0AA remote object isn't registered wit=
h a lookup service. =C2=A0Listeners are typically remote objects. =C2=A0In =
OSGi, it is advisable for remote objects to be dynamic proxy's without a co=
debase. =C2=A0Remote Object proxy's will be deserialized into the remote endpoint's nominated Cl=
assLoader. =C2=A0For example, if it is transferred via a service, the remot=
e object's dynamic proxy stub will be loaded into the service's proxy bundl=
e ClassLoader in the server jvm.=0A=0AAs Nic pointed out earlier, Bundle Cl=
assLoader's are not instances of URLClassLoader and lack codebase annotatio=
ns as a result.=0A=0AWith the above rules in place, there is no need to cre=
ate a custom RMIClassLoaderSpi specific to OSGi.=0A=0AWith the above rules =
in place, it does open up an opportunity to use a remote object (eg a liste=
ner) with a conventional codebase as Mic had requested. =C2=A0 This would u=
se the PreferredClassProvider infrastructure, so the remote object proxy Pr=
eferredClassLoader would utilise the services server jvm proxy bundle Class=
Loader as it's parent. =C2=A0This style of remote object should not be regi=
stered as a remote service.=0A=0AI would probably discourage this use case,=
 except for advanced users.=0A=0AI think we need to make a distinction betw=
een remote services and remote objects for OSGi.=0A=0AThis is a very practical =
solution for OSGi.=0A=0ARegards,=0A=0APeter.=0A=0A=0ASent from my Samsung d=
evice.=0A=C2=A0

--8323328-1289003160-1487827575=:1321
Content-Type: TEXT/html; CHARSET=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

<html><body><div dir=3D"auto">I've attached some ASCII of the relationship =
between server and client jvm bundles.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">The ClassLoader at the server is set using the invocation la=
yer factory (a configuration item).</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">The client ClassLoader is determined during delayed unmarshalli=
ng and smart proxy bundle provisioning.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">This ensures that deserialization at each endpoint has a co=
mpatible view of classes (as recently discussed on osgi-dev).</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">It's important at this time to distin=
guish between remote objects and remote services, registered with a lookup =
service.</div><div dir=3D"auto"><br></div><div dir=3D"auto">A remote servic=
e must have a proxy bundle for OSGi. &nbsp;The proxy bundle manifest determ=
ines requirements and wiring to package import versions. &nbsp;This include=
s dynamic proxy based services.</div><div dir=3D"auto"><br></div><div dir=3D"auto">For arguments sake, a remote object becomes a remote service wh=
en it is registered with a lookup service.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">A remote object isn't registered with a lookup service. =
&nbsp;Listeners are typically remote objects. &nbsp;In OSGi, it is advisabl=
e for remote objects to be dynamic proxy's without a codebase. &nbsp;Remote=
 Object proxy's will be deserialized into the remote endpoint's nominated C=
lassLoader. &nbsp;For example, if it is transferred via a service, the remo=
te object's dynamic proxy stub will be loaded into the service's proxy bund=
le ClassLoader in the server jvm.<br><br>As Nic pointed out earlier, Bundle=
 ClassLoader's are not instances of URLClassLoader and lack codebase annota=
tions as a result.</div><div dir=3D"auto"><br></div><div dir=3D"auto">With =
the above rules in place, there is no need to create a custom RMIClassLoade=
rSpi specific to OSGi.</div><div dir=3D"auto"><br></div><div dir=3D"auto">W=
ith the above rules in place, it does open up an opportunity to use a remote object (eg a listener) with a conventional codebase as Mic =
had requested. &nbsp; This would use the PreferredClassProvider infrastruct=
ure, so the remote object proxy PreferredClassLoader would utilise the serv=
ices server jvm proxy bundle ClassLoader as it's parent. &nbsp;This style o=
f remote object should not be registered as a remote service.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">I would probably discourage this use =
case, except for advanced users.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">I think we need to make a distinction between remote services and=
 remote objects for OSGi.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">This is a very practical solution for OSGi.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">Regards,</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Peter.</div><div dir=3D"auto"><br><br><div dir=3D"auto" class=3D"tiz=
en_signature">Sent from my Samsung device.</div>&nbsp;</div>=0A=0A=0A=0A=0A=
</body></html>

--8323328-1289003160-1487827575=:1321--

--8323328-1424321324-1487827575=:1321--