Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
From: Gregg Wonderly <gregg@wonderly.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: OSGi
Date: Thu, 26 Jan 2017 08:35:44 -0600
References: <ee4e81f255d582989de35eff650dec10@org.tizen.email>
 <CA+JOpGSGhZpKSvQ5Fqeic4AcynMsLOrbn+th3o83E6KMTee_jg@mail.gmail.com>
 <5882A694.2020701@zeus.net.au>
To: dev@river.apache.org
In-Reply-To: <5882A694.2020701@zeus.net.au>
Message-Id: <16143BFF-FDD7-44B1-8422-D272713FAABC@wonderly.org>
Sender: Gregg Wonderly <gregg@wonderly.org>
archived-at: Thu, 26 Jan 2017 14:48:33 -0000

Is there any thought here about how a single client might use both an =
OSGi deployed service and a conventionally deployed service?  The =
ContextClassLoader is a good abstraction mechanism for finding =E2=80=9Cth=
e=E2=80=9D appropriate class loader.  It allows applications to deploy a =
composite class loader in some form that would be able to resolve =
classes from many sources and even provide things like preferred =
classes. =20

In a Java desktop application, would a transition from a background =
thread, interacting with a service to get an object from a service which =
is not completely resolved to applicable loaders still resolve correctly =
in an EventDispatch Thread?  That event dispatch thread can have the =
context class loader set on it by the thread which got the object, to be =
the class loader of the service object, to make sure that the resolution =
of classes happens with the correct class loader such that there will =
not be a problem with the service object having one set of definitions =
and another service or the application classpath having a conflicting =
class definition by the same name.

I=E2=80=99ve had to spend quite a bit of time to make sure that these =
scenarios work correctly in my Swing applications.

Gregg

> On Jan 20, 2017, at 6:08 PM, Peter <jini@zeus.net.au> wrote:
>=20
> Looking at your modifications to ServiceDiscoveryManager, I noticed =
you've made changes to set the context ClassLoader prior to calling the =
lookup service.
>=20
> This is eventually utilised by PreferredClassProvider to lookup the =
necessary loader to utilise for deserialization of the lookup results.
>=20
> I think if we develop a RMIClassLoader provider for OSGi, we can avoid =
utilising the context ClassLoader.
>=20
> 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.
>=20
> Cheers,
>=20
> Peter.
>=20
> On 20/01/2017 11:09 PM, Bharath Kumar wrote:
>> Thanks Peter for the review.
>>=20
>> 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.
>>=20
>>=20
>> 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.
>>=20
>>=20
>> Thanks&  Regards,
>> Bharath
>>=20
>>=20
>> On Fri, Jan 20, 2017 at 6:09 PM, Peter<jini@zeus.net.au>  wrote:
>>=20
>>> Hi Bharath,
>>>=20
>>> Re your changes (I've found so far):
>>>=20
>>> LookupDiscoveryManager is non final, I'm interested why?
>>>=20
>>> 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.
>>>=20
>>> Regarding bundle structure, I've restructured the layout here (so =
you
>>> don't need to delete Groovy config):
>>>=20
>>> =
https://github.com/pfirmstone/JGDMS/tree/Maven_build/modularize/JGDMS
>>>=20
>>> The full commit history has been retained, so u can see all changes.
>>>=20
>>> Cheers,
>>>=20
>>> Peter.
>>>=20
>>> Sent from my Samsung device.
>>>=20
>>>  Include original message
>>> ---- Original message ----
>>> From: Bharath Kumar<bharathkumar.a@gmail.com>
>>> Sent: 20/01/2017 09:42:38 pm
>>> To: dev@river.apache.org
>>> Subject: Re: OSGi
>>>=20
>>> Hello all,
>>>=20
>>> I have also added a package in org.apache.river bundle to create the =
river
>>> service in osgi environment ( Here RIver
>>> uses NonActivatableServiceDescriptor).
>>>=20
>>> package name is  org.apache.river.start.ext
>>>=20
>>>=20
>>> As river bundle is system fragment, i have to remove
>>> the groovy dependency.
>>> So i removed groovy files.
>>>=20
>>> net.jini.config.Component.groovy
>>>=20
>>> net.jini.config.GroovyConfig.groovy
>>>=20
>>>=20
>>>=20
>>> Thanks&  Regards,
>>>=20
>>> Bharath
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On Fri, Jan 20, 2017 at 3:47 PM, Bharath =
Kumar<bharathkumar.a@gmail.com>
>>> wrote:
>>>=20
>>>> I missed images. Please find the zip file which has
>>> report.html along with
>>>> images.
>>>>=20
>>>> On Fri, Jan 20, 2017 at 3:42 PM, Bharath =
Kumar<bharathkumar.a@gmail.com
>>>>=20
>>>> wrote:
>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Fri, Jan 20, 2017 at 12:45 PM, Bharath Kumar<bharathk
>>> umar.a@gmail.com
>>>>>> wrote:
>>>>>> Thanks Peter,
>>>>>>=20
>>>>>> I have uploaded 3 bundles to github and it is available in the =
below
>>>>>> location.
>>>>>> https://github.com/bharathkumara/river-osgi
>>>>>>=20
>>>>>> It is eclipse workspace and we need bndtools eclipse
>>> plugin to run/debug
>>>>>> it.
>>>>>>=20
>>>>>>   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.
>>>>>>=20
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> We can use lookup.bndrun to test the lookup service.
>>>>>>=20
>>>>>> 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
>>>>>>=20
>>>>>> start the lookup using the below command
>>>>>> lookup start
>>>>>>=20
>>>>>> stop the lookup using the below command
>>>>>> lookup stop
>>>>>>=20
>>>>>> Get the running status of the lookup service
>>>>>> lookup
>>>>>>=20
>>>>>>=20
>>>>>> 6. We can use registrars command to list available lookup =
services in
>>>>>> network
>>>>>>=20
>>>>>> registrars
>>>>>>=20
>>>>>>=20
>>>>>> Please let me know your feedback.
>>>>>>=20
>>>>>>=20
>>>>>> Thanks&  Regards,
>>>>>> Bharath
>>>>>>=20
>>>>>>=20
>>>>>> On Fri, Jan 20, 2017 at 7:51 AM, Peter<jini@zeus.net.au>  wrote:
>>>>>>=20
>>>>>>> Thanks Bharath, welcome to Apache River!
>>>>>>>=20
>>>>>>> Interesting, are you able to create an OSGi support task on Jira =
and
>>>>>>> upload a patch?
>>>>>>>=20
>>>>>>> Cheers,
>>>>>>>=20
>>>>>>> Peter.
>>>>>>>=20
>>>>>>> Sent from my Samsung device.
>>>>>>>=20
>>>>>>>  Include original message
>>>>>>> ---- Original message ----
>>>>>>> From: Bharath Kumar<bharathkumar.a@gmail.com>
>>>>>>> Sent: 20/01/2017 04:22:02 am
>>>>>>> To: dev@river.apache.org
>>>>>>> Subject: Re: OSGi
>>>>>>>=20
>>>>>>> Hello all,
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> I am using eclipse and bndtools for the development. I am re
>>>>>>> ady to share
>>>>>>> these 3 bundles to this great community.
>>>>>>>=20
>>>>>>> Thanks&  Regards,
>>>>>>> Bharath
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> On Jan 19, 2017 8:55 AM, "Peter"<jini@zeus.net.au>  wrote:
>>>>>>>=20
>>>>>>> Thanks Nic&  Richard, will follow up your leads.
>>>>>>>=20
>>>>>>> Peter.
>>>>>>>=20
>>>>>>> Sent from my Samsung device.
>>>>>>>=20
>>>>>>>  Include original message
>>>>>>> ---- Original message ----
>>>>>>> From: Niclas Hedhman<niclas@hedhman.org>
>>>>>>> Sent: 18/01/2017 08:34:11 pm
>>>>>>> To: dev@river.apache.org
>>>>>>> Subject: Re: OSGi
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>>=20
>>>>>>> [1] https://ops4j1.jira.com/wiki/display/paxurl/Pax+URL
>>>>>>>=20
>>>>>>> On Wed, Jan 18, 2017 at 11:18 AM, Peter Firmstone<
>>>>>>> peter.firmstone@zeus.net.au>  wrote:
>>>>>>>=20
>>>>>>>> Any OSGi veterans willing to assist with JGDMS support for
>>>>>>> OSGi during the
>>>>>>>> modular restructure?
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>>> River also has its own service provider lookup mechanism:
>>>>>>>> org.apache.resources.Service
>>>>>>>>=20
>>>>>>>> Then there's the use of context ClassLoader's
>>> throughout to consider.
>>>>>>>> Regards,
>>>>>>>>=20
>>>>>>>> Peter.
>>>>>>>>=20
>>>>>>>> Sent from my Samsung device.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> --
>>>>>>> Niclas Hedhman, Software Developer
>>>>>>> http://polygene.apache.org<http://zest.apache.org>  - New En
>>>>>>> ergy for Java
>>>>>>>=20
>>>>>>>=20
>>>=20
>>>=20
>>>=20
>=20