Thanks Bharath,
Interesting, thank you for your explanation on how
ServiceTemplateTracker works. PreferredClassProvider creates a
PreferredClassLoader for each smart proxy, in your case, the
ServiceTemplate, remembers the bundle and that bundle's ClassLoader will
also be the parent loader of the PreferredClassLoader instance.
Jini / River uses the ClassLoader of the proxy to represent the
service's identity on the client.
I agree with your suggested 3 bundle layout for services. In this
scenario, the client will have visibility of the api bundle, as will the
proxy, but neither the client or the proxy will have visibility of each
others classes, they will interact using classes defined in the api
bundle. Of course both proxy and client will need to have visibility to
the same api bundle. In JGDMS I've followed this layout for services,
proxy's and api, in JGDMS' case though, the api bundle is part of the
Jini platform.
I'd like to also make it possible for services to specify their own code
/ bundle repository's, just in case the smart proxy bundle hasn't been
publicly released for example and isn't available from a configured
bundle repository. This should, along with signing a proxy's bundle,
allow an implementer to avoid sharing the bundle with other service proxy's.
Nic also mentioned PAX URL, it does look promising,
There's a RFC3986 compliant Uri class in org.apache.river.api.net, this
can be used as a Map key, allowing a cache to be built up with codebase
annotation key's referring to every ClassLoader in the JVM. A
SecurityManager will be exposed to every ProtectionDomain in the JVM so
could interact with the RMIClassLoader.
River has a number of server provider instances, RMIClassLoader being
one of them, potentially these could be made available from the OSGi
service registry.
Security in River is a little different, it's also capable of making
dynamic grants and revocation, but currently doesn't support deny or
conditions. It does have its own pluggable policy parser mechanism, so
could potentially be utilised to implement ConditionalPermissionAdmin
and read OSGi style policy files. One reason for doing so, is the River
security infrastructure has a much lower performance penalty, <1%, in
comparison to Java's approxy 10%, but more importantly is scalable,
where Java's security policy implementation is not. Modifications I've
made in JGDMS, make it possible to authenticate a service, prior to
granting DownloadPermission and DeserializationPermission, client code
could also utilise the OSGi means of dynamically granting permission
such as via ConditionalPermissionAdmin via ProxyPreparer.
I haven't as yet looked through all your work, but will continue to do
so and ask more questions.
Cheers,
Peter.
On 21/01/2017 2:14 PM, Bharath Kumar wrote:
Thanks Peter.
Yes. I observed that most of integration problems come in deserialization
process.
I didn't face much problems in serialization process.
In OSGI, every bundle is loaded by a class loader. So we need to remember
the bundle which has requested the network service.
I have created the bootstrap bundle to do these kind of tasks. If a bundle
requires a network service, then it will register a service
(ServiceTemplate) into OSGI registry. ServiceTemplateTracker class tracks
these ServiceTemplate services and remember the bundle which has requested.
Internally tracker will initiate the service discovery process using
ServiceDiscoveryManager.createLookupCache method and implements
ServiceDiscoveryListener and stores the bundle reference. So whenever a
network service is found, it will deserialize the object using bundle class
loader which is already known.
ServiceTemplateTracker class handles OSGI service dynamism, if
ServiceTemplate service is registered in OSGI registry, it will start the
river discovery process. If ServiceTemplate service is unregistered, it
will terminate the discovery process. These classes are available in the
package org.apache.river.bootstrap.client.internal.
Regarding OSGI environment aware RMIClassLoader provider.
Yes, that will be good approach.
In OSGI, each bundle has its own class loader.
It would be better to create a standard model for smart proxy based
services
For smart proxy based services, We can create 3 osgi bundle projects api
bundle, service Bundle, proxy bundle.
1. All 3 bundle are required at provider vm. API bundle and proxy
bundles are required at consumer vm,
2. We can annotate the proxy object using osgi bundle symbolic name and
version.
3. RMIClassLoader provider can check whether the proxy bundle is
installed or not, If it is not installed, it can install it from configured
repo ( like OBR). We can even use pax-url which adds different URL handlers.
4. Load class/proxy class from correct proxy bundle
5. Security permission is another area where we can use conditional
permission admin.
Thanks once again .
Regards,
Bharath
On Sat, Jan 21, 2017 at 5:38 AM, Peter<j...@zeus.net.au> wrote:
Looking at your modifications to ServiceDiscoveryManager, I noticed you've
made changes to set the context ClassLoader prior to calling the lookup
service.
This is eventually utilised by PreferredClassProvider to lookup the
necessary loader to utilise for deserialization of the lookup results.
I think if we develop a RMIClassLoader provider for OSGi, we can avoid
utilising the context ClassLoader.
Since all OSGi ClassLoader's are instances of BundleReference, it's easy
to utilise OSGi bundle url anotations (I think this needs to incorporate
bundle versions). I'd also like to utilise Java 9 jrt style URL's.
Cheers,
Peter.
On 20/01/2017 11:09 PM, Bharath Kumar wrote:
Thanks Peter for the review.
While creating this POC, I tried to make RIO framework as set of OSGI.
bundles. Rio project extends LookupDiscoveryManager class in one of the
class .org.rioproject.impl.client.DiscoveryManagementPool.SharedDi
scoveryManager.
That's why I removed the final modifier.
Regarding groovy files,
I have made the org.apache.river as system fragment bundle. So we can't
import any packages from other bundles. But we can use system bundle's
packages,. That's why i removed groovy files. If we use these groovy
files,
we need to import packages from groovy bundle which is not possible here.
I
will check JGDMS to see how it is used.
Thanks& Regards,
Bharath
On Fri, Jan 20, 2017 at 6:09 PM, Peter<j...@zeus.net.au> wrote:
Hi Bharath,
Re your changes (I've found so far):
LookupDiscoveryManager is non final, I'm interested why?
BasicInvocationDispatcher, you've set the context class loader around a
block of code, to use the ClassLoader passed in during construction. I'm
currently investigating addong methods where ClassLoader can be passed in
for OSGi.
Regarding bundle structure, I've restructured the layout here (so you
don't need to delete Groovy config):
https://github.com/pfirmstone/JGDMS/tree/Maven_build/modularize/JGDMS
The full commit history has been retained, so u can see all changes.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Bharath Kumar<bharathkuma...@gmail.com>
Sent: 20/01/2017 09:42:38 pm
To: dev@river.apache.org
Subject: Re: OSGi
Hello all,
I have also added a package in org.apache.river bundle to create the
river
service in osgi environment ( Here RIver
uses NonActivatableServiceDescriptor).
package name is org.apache.river.start.ext
As river bundle is system fragment, i have to remove
the groovy dependency.
So i removed groovy files.
net.jini.config.Component.groovy
net.jini.config.GroovyConfig.groovy
Thanks& Regards,
Bharath
On Fri, Jan 20, 2017 at 3:47 PM, Bharath Kumar<bharathkuma...@gmail.com>
wrote:
I missed images. Please find the zip file which has
report.html along with
images.
On Fri, Jan 20, 2017 at 3:42 PM, Bharath Kumar<bharathkuma...@gmail.com
wrote:
I have attached the comparison report (html) between river 3.0.0 source
and org.apache.river bundle source.
I made changes to those files which are in red color.
On Fri, Jan 20, 2017 at 12:45 PM, Bharath Kumar<bharathk
uma...@gmail.com
wrote:
Thanks Peter,
I have uploaded 3 bundles to github and it is available in the below
location.
https://github.com/bharathkumara/river-osgi
It is eclipse workspace and we need bndtools eclipse
plugin to run/debug
it.
1. org.apache.river - River classes as system fragment bundle
2. org.apache.river.bootstrap - Contains code to
start code server,
export local osgi services(Remote) and publish
it to network, listen for
river services in the network and utilities.
3. org.apache.river.lookup - Lookup service as osgi bundle.
Using these 3 osgi bundles, I am able to start reggie and clients can
register services and lookup using service templates.
I'll post example services later.
We can use lookup.bndrun to test the lookup service.
Steps to follow
1. Install Eclipse and Bndtools plugin
2. Import these 4 projects into eclipse
3. open the file lookup.bndrun which is located in
org.apache.riverlookup project
4. Run/ debug it and it will open the gogo shell in console view.
5. I have written ad-hoc gogo shell command to start/stop the lookup
service
start the lookup using the below command
lookup start
stop the lookup using the below command
lookup stop
Get the running status of the lookup service
lookup
6. We can use registrars command to list available lookup services in
network
registrars
Please let me know your feedback.
Thanks& Regards,
Bharath
On Fri, Jan 20, 2017 at 7:51 AM, Peter<j...@zeus.net.au> wrote:
Thanks Bharath, welcome to Apache River!
Interesting, are you able to create an OSGi support task on Jira and
upload a patch?
Cheers,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Bharath Kumar<bharathkuma...@gmail.com>
Sent: 20/01/2017 04:22:02 am
To: dev@river.apache.org
Subject: Re: OSGi
Hello all,
I am Bharath kumar and this is my first mail to this group.
I am following
River framework for the last 8 years. I have been using OSGi
framework for
the past 7 years in various projects.
I made lot of attempts to use jini with OSGi framework.
Recently I got some success using River 3.0.0
version. I created 3 OSGi
bundles based on River code.
1. River core classes as system fragment bundle.
2. Bootstrap bundle to start code server, Lookup discovery m
anager, export
remote services.
3. Lookup service.
I made some minor changes to River classes (10 Classes) to r
esolve class
loading issues. I have excluded other services like transact
ion services,
Java space services.
I am using eclipse and bndtools for the development. I am re
ady to share
these 3 bundles to this great community.
Thanks& Regards,
Bharath
On Jan 19, 2017 8:55 AM, "Peter"<j...@zeus.net.au> wrote:
Thanks Nic& Richard, will follow up your leads.
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Niclas Hedhman<nic...@hedhman.org>
Sent: 18/01/2017 08:34:11 pm
To: dev@river.apache.org
Subject: Re: OSGi
Also, I am still on this list, and can aid with answering question in
details, but not really to put in hours to do the actual work.
The maven-bnd-plugin does most things right, but there is al
ways a question
of hiding internal packages/classes. Instead of aiming for r
unning 'naked'
on a blank OSGi container, I think it is generally better to
start out with
something like Apache Karaf. It will provide a lot for relat
ively little,
incl so called wrapping of JARs into Bundles, provided by Pax URL[1]
project, which also provides URL references of various kinds for many
things. So, even if not going with Karaf, take a look at Pax URL.
And in River, there is likely to be classloading issues, and although
"Dynamic-ImportPackage" is available as a last resort, it should be
avoided. Almost always the context classloader is a "mess",
and there is a
tendency of memory leaks when it is involved.
[1] https://ops4j1.jira.com/wiki/display/paxurl/Pax+URL
On Wed, Jan 18, 2017 at 11:18 AM, Peter Firmstone<
peter.firmst...@zeus.net.au> wrote:
Any OSGi veterans willing to assist with JGDMS support for
OSGi during the
modular restructure?
I've added OSGi manifests to modules, but I also need to a
dd classpath
manifest entry's for non osgi application compatibility, I
'm using the
bnd-maven-plugin to generate the OSGi manifests.
I also want to enable using ServiceLoader mediator manife
st entry's for
OSGi, as the use of service provider style abstractions wi
thin River are
widespread.
River also has its own service provider lookup mechanism:
org.apache.resources.Service
Then there's the use of context ClassLoader's
throughout to consider.
Regards,
Peter.
Sent from my Samsung device.
--
Niclas Hedhman, Software Developer
http://polygene.apache.org<http://zest.apache.org> - New En
ergy for Java
