It is early in the morning, and I am probably not clear enough in the head
yet, but I would like to point out two things about OSGi which may not be
clear;

1. There is no "need" for BundleA and BundleB to "use" a BundleC to avoid
sharing classes. The BundleC classes, which are stable API and exposed, can
be in either BundleA or BundleB, and in some cases it may even make sense
to put them in both BundleA and BundleB, yet there will not be class space
errors, if Export/Import packages are done properly. There might be other
reasons to have a BundleC, such as ability to not stop bundles when BundleA
or BundleB reloads.

2. A common and popular pattern for OSGi extensibility is the Whiteboard
pattern (sometimes called Extender pattern), where the main service will
listen to registrations of services and 'wire' such registered service into
the main service's functionality. For instance, a web server service
listens for OSGi registrations of Servlet classes, and binds/unbinds those
to the web server dynamically. This is popular, because the 'effort' to
register is with the more complicated service, rather than with the
extension, which doesn't have to track the main service at all, nor issue
the registration/deregistration with it.
Also, since Declarative Services Specification is 'sugar', this means that
a single <code>@Component(iimmediate=yes)</code> is all there is to
register such and extension.
.

I hope to provide more understanding of "the OSGi way" and how it will
'induce' different thinking.

Cheers
Niclas

On Sun, Jan 22, 2017 at 7:57 PM, Peter <j...@zeus.net.au> wrote:

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


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

Reply via email to