Re: OSGi

[Peter]

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.SharedDiscoveryManager.
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