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 “the” 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.
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’ve 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 <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.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 >>>>>>> >>>>>>> >>> >>> >>> >
