Re: OSGi

[Michał Kłeczek (XPro Sp. z o. o.)]

Honestly - since I am fixed ( :-) ) on having mobile code treated as any 
other object - I see it something like:


interface CodeBaseModule {
  ClassLoader createLoader() throws AnyImportantException;
}

interface CodeRepository {
  CodeBaseModule getCodeBaseModule(String name, Version version);
  boolean isSameNamespace(CodeRepository other);
}

class NamedCodeBase {
  String name; Version version;
  CodeRepository repository;
  boolean equals(Object other) { //check name, version and repo }
}

Now the question is about the implementation of "isSameNamespace". Since 
the protocol(s) to access code repository might differ (and there might 
be multiple available at the same time), location based equality won't 
work (although is the easiest to implement). My rough idea is for the 
CodeRepository to be able to authenticate as any of a set of Principals 
( ie. satisfy the ServerMinPrincipal constraint ). Two CodeRepository 
instances are interchangeable if intersection of their principal sets is 
non-empty.


At first I thought about having a global naming scheme - then 
cryptographic hash would constitute the part of the name. But that would 
make names obscure and difficult to remember and write by hand.
So I came up with an idea to abstract it away - according to "all 
problems in CS can be solved by introducing another level of indirection" :)


Thanks,
Michal

Peter wrote:

codebase identity

So River codebase identity is currently any number of space delimited RFC 3986 
normalised URI strings.

httpmd uses a location filename and message digest.

But should location be part of identity?  How can you relocate a codebase once 
remote objects are deployed?

OSGi and Maven use a name and version to identify a codebase.  


Might we also need codebase signers (if any) to be part of identity?

If no, why not and if yes why?

Regards,

Peter.

Sent from my Samsung device.
  
   Include original message

 Original message 
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 26/01/2017 08:30:58 am
To: d...@riverapache.org
Subject: Re: OSGi

I haven't been aware of ObjectSpace Voyager. I just briefly looked at it 
and it seems like it is based on Java 1.x (ancient beast) and - as I 
understand it - the issues you describe are mainly caused by having only 
a single class name space (single ClassLoader).


But sending IMHO class bytes in-band is not necessary (nor good).

What is needed is:
1. Encoding dependency information in codebases (either in-band or by 
providing a downloadable descriptor) so that it is possible to recreate 
proper ClassLoader structure (hierarchy or rather graph - see below) on 
the client.
2. Provide non-hierarchical class loading to support arbitrary object 
graph deserialization (otherwise there is a problem with "diamond 
shaped" object graphs).


A separate issue is with the definition of codebase identity. I guess 
originally Jini designers wanted to avoid this issue and left it 
undefined... but it is unavoidable :)


Thanks,
Michal

Gregg Wonderly wrote:

  That’s what I was suggesting.  The code works, but only if you put the 
required classes into codebases or class paths.  It’s not a problem with mobile 
code, it’s a problem with resolution of objects in mobile code references.  
That’s why I mentioned ObjectSpace Voyager.  It automatically sent/sends class 
definitions with object graphs to the remote VM.

  Gregg


  On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. 
o.)   wrote:

  The problem is that we only support (smart) proxies that reference only 
objects of classes from their own code base.
  We do not support cases when a (smart) proxy wraps a (smart) proxy of another 
service (annotated with different codebase).

  This precludes several scenarios such as for example "dynamic exporters" - 
exporters that are actually smart proxies.

  Thanks,
  Michal

Re: OSGi

[Peter]

codebase identity

So River codebase identity is currently any number of space delimited RFC 3986 
normalised URI strings.

httpmd uses a location filename and message digest.

But should location be part of identity?  How can you relocate a codebase once 
remote objects are deployed?

OSGi and Maven use a name and version to identify a codebase.  

Might we also need codebase signers (if any) to be part of identity?

If no, why not and if yes why?

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: "Michał Kłeczek (XPro Sp. z o. o.)" 
Sent: 26/01/2017 08:30:58 am
To: d...@riverapache.org
Subject: Re: OSGi

I haven't been aware of ObjectSpace Voyager. I just briefly looked at it  
and it seems like it is based on Java 1.x (ancient beast) and - as I  
understand it - the issues you describe are mainly caused by having only  
a single class name space (single ClassLoader). 

But sending IMHO class bytes in-band is not necessary (nor good). 

What is needed is: 
1. Encoding dependency information in codebases (either in-band or by  
providing a downloadable descriptor) so that it is possible to recreate  
proper ClassLoader structure (hierarchy or rather graph - see below) on  
the client. 
2. Provide non-hierarchical class loading to support arbitrary object  
graph deserialization (otherwise there is a problem with "diamond  
shaped" object graphs). 

A separate issue is with the definition of codebase identity. I guess  
originally Jini designers wanted to avoid this issue and left it  
undefined... but it is unavoidable :) 

Thanks, 
Michal 

Gregg Wonderly wrote: 
> That’s what I was suggesting.  The code works, but only if you put the 
>required classes into codebases or class paths.  It’s not a problem with 
>mobile code, it’s a problem with resolution of objects in mobile code 
>references.  That’s why I mentioned ObjectSpace Voyager.  It automatically 
>sent/sends class definitions with object graphs to the remote VM. 
> 
> Gregg 
> 
>> On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. 
>>o.)  wrote: 
>> 
>> The problem is that we only support (smart) proxies that reference only 
>>objects of classes from their own code base. 
>> We do not support cases when a (smart) proxy wraps a (smart) proxy of 
>>another service (annotated with different codebase). 
>> 
>> This precludes several scenarios such as for example "dynamic exporters" - 
>>exporters that are actually smart proxies. 
>> 
>> Thanks, 
>> Michal 
>> 
>> 

Re: OSGi

[Michał Kłeczek (XPro Sp. z o. o.)]

I haven't been aware of ObjectSpace Voyager. I just briefly looked at it 
and it seems like it is based on Java 1.x (ancient beast) and - as I 
understand it - the issues you describe are mainly caused by having only 
a single class name space (single ClassLoader).


But sending IMHO class bytes in-band is not necessary (nor good).

What is needed is:
1. Encoding dependency information in codebases (either in-band or by 
providing a downloadable descriptor) so that it is possible to recreate 
proper ClassLoader structure (hierarchy or rather graph - see below) on 
the client.
2. Provide non-hierarchical class loading to support arbitrary object 
graph deserialization (otherwise there is a problem with "diamond 
shaped" object graphs).


A separate issue is with the definition of codebase identity. I guess 
originally Jini designers wanted to avoid this issue and left it 
undefined... but it is unavoidable :)


Thanks,
Michal

Gregg Wonderly wrote:

That’s what I was suggesting.  The code works, but only if you put the required 
classes into codebases or class paths.  It’s not a problem with mobile code, 
it’s a problem with resolution of objects in mobile code references.  That’s 
why I mentioned ObjectSpace Voyager.  It automatically sent/sends class 
definitions with object graphs to the remote VM.

Gregg


On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. 
o.)  wrote:

The problem is that we only support (smart) proxies that reference only objects 
of classes from their own code base.
We do not support cases when a (smart) proxy wraps a (smart) proxy of another 
service (annotated with different codebase).

This precludes several scenarios such as for example "dynamic exporters" - 
exporters that are actually smart proxies.

Thanks,
Michal

Re: OSGi

[Bharath Kumar]

I propose the following steps to create smart river services in OSGI
environment.

Service provider side.

1. Create 4 osgi bundles as described below. All these bundles can import,
export packages like regular osgi bundles.

1. Service API  - This bundle contains service interfaces and supporting
classes. This bundle will be available at both provider and consumer side.
2. Proxy - This osgi bundle depends on service API bundle and imports
packages from it. It may import packages from other bundles also. Initially
this bundle will be available at service provider side and later downloaded
by the consumer. Please note that this bundle will not be deployed in osgi
container.
3. Service implementation - depends on service api and proxy bundles. Like
reggie, it may use private communication protocol. It imports packages from
api and proxy bundles. It may import additional packages from other bundles
also. Please note that this bundle will not be deployed in osgi container.
4. Service bootstrap bundle - This bundle wraps proxy bundle jar and
service implemetation bundle jar files as resource files. These jar files
will not be in the classpath. This bootstrap bundle imports all packages
that are required by proxy bundle and service implementation bundles, even
though it doesn't use these packages internally. This bundle registers a
"ServiceDescriptor" (example NonActivatableServiceDescriptor) service into
osgi registry.
classpath - URLs of proxy and service implementation jar files which are
inside the bootstrap bundle.
export codebase - location where user can download the proxy bundle (pax
url can be used)
impl class - service implementation class
policy and configuration can be supplied

2. We can implement a ServiceTracker(OSGI) to track these ServiceDescriptor
services. Whenever a ServiceDescriptor is registered into OSGI registry, we
can process these descriptors from this ServiceTracker.
I observered that NonActivatableServiceDescriptor implementation creates a
PreferredClassLoader instance and uses the context classloader as parent.
Before calling the ServiceDescriptod's create method, we can set the
bundle's class loader as context class loader. So classes that are required
for service implementation and proxy jars will be available through bundle
class loader.
As bootstrap bundle is already importing packages that are required by
proxy bundle and service implementation bundle, these classes will be
available to preferredClassLoader instance.  As PreferredClassLoader
implements ClassAnnotation interface, smart proxy instance will be
annotated with proxy bundle location. River classes are already available
from framework class loader which is parent for all bundles.


Modifications required?
1. We can provide some abstraction in river code to create smart services (
codebase, classpath, implementation class name)
2. policy and configuration can be passed via osgi configuration admin
service.
3. We need to create a service tracker to track these smart service
instances. In the service tracker,
we will set the bundle class loader as context class loader before creating
the service instance and proxy.


In the POC, I have wrapped lookup service(reggie.jar) and dl
file(reggie-dl.jar) as regular jar files.
Service API classes are already available from river fragment. These api
classes will be available from framework class loader.
I have also made few modifications with NonActivatableServiceDescriptor.
But this is not required.



I'll describe about the client side of smart service in the next mail.





On Tue, Jan 24, 2017 at 9:08 AM, Gregg Wonderly  wrote:

> That’s what I was suggesting.  The code works, but only if you put the
> required classes into codebases or class paths.  It’s not a problem with
> mobile code, it’s a problem with resolution of objects in mobile code
> references.  That’s why I mentioned ObjectSpace Voyager.  It automatically
> sent/sends class definitions with object graphs to the remote VM.
>
> Gregg
>
> > On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. o.) <
> michal.klec...@xpro.biz> wrote:
> >
> > The problem is that we only support (smart) proxies that reference only
> objects of classes from their own code base.
> > We do not support cases when a (smart) proxy wraps a (smart) proxy of
> another service (annotated with different codebase).
> >
> > This precludes several scenarios such as for example "dynamic exporters"
> - exporters that are actually smart proxies.
> >
> > Thanks,
> > Michal
> >
> > Gregg Wonderly wrote:
> >> I guess I am not sure then what you are trying to show with your
> example.
> >>
> >> Under what case would the SpacePublisher be sent to another VM, and how
> is that different from normal SmartProxy deserialization?
> >>
> >> Gregg
> >

Re: OSGi

[Gregg Wonderly]

That’s what I was suggesting.  The code works, but only if you put the required 
classes into codebases or class paths.  It’s not a problem with mobile code, 
it’s a problem with resolution of objects in mobile code references.  That’s 
why I mentioned ObjectSpace Voyager.  It automatically sent/sends class 
definitions with object graphs to the remote VM.

Gregg

> On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. o.) 
>  wrote:
> 
> The problem is that we only support (smart) proxies that reference only 
> objects of classes from their own code base.
> We do not support cases when a (smart) proxy wraps a (smart) proxy of another 
> service (annotated with different codebase).
> 
> This precludes several scenarios such as for example "dynamic exporters" - 
> exporters that are actually smart proxies.
> 
> Thanks,
> Michal
> 
> Gregg Wonderly wrote:
>> I guess I am not sure then what you are trying to show with your example.
>> 
>> Under what case would the SpacePublisher be sent to another VM, and how is 
>> that different from normal SmartProxy deserialization?
>> 
>> Gregg
>> 
>>> On Jan 23, 2017, at 2:39 PM, Michał Kłeczek (XPro Sp. z o. o.) 
>>>   wrote:
>>> 
>>> 
>>> 
>>> Gregg Wonderly wrote:
> michal.klec...@xpro.biz  
>   
>   
>  > wrote:
>>> The use case and the ultimate test to implement is simple - have a
>> listener that publishes remote events to a JavaSpace acquired dynamically
>> from a lookup service:
>>> class SpacePublisher implements RemoteEventListener, Serializable {
>>>   private final JavaSpace space;
>>>   public void notify(RemoteEvent evt) {
>>> space.write(createEntry(evt), ...);
>>>   }
>>> }
>>> 
>>> It is NOT possible to do currently. It requires non-hierarchical class
>> loading. It is not easy to solve. It would open a whole lot of
>> possibilities.
>> 
>> I am probably too ignorant to see it; What exactly is "NOT possible" with
>> the above use-case snippet?
> With currently implemented PreferredClassProvider it is not possible to 
> deserialize such an object graph.
 This can happen, but what’s necessary is that the codebase of the 
 SpacePublisher needs to include all the possible RemoteEvent classes, or 
 the javaspace’s classpath has to include them.   
>>> I am not sure I understand.
>>> The problem does not have anything to do with RemoteEvent (sub)classes. The 
>>> issue is that SpacePublisher cannot be deserialized at all ( except one 
>>> case when JavaSpace interface is available from context class loader and it 
>>> is not marked as preferred in SpacePublisher code base).
>>> 
>>> Michal
>> 
>> 
> 

Re: OSGi

[Michał Kłeczek (XPro Sp. z o. o.)]

The problem is that we only support (smart) proxies that reference only 
objects of classes from their own code base.
We do not support cases when a (smart) proxy wraps a (smart) proxy of 
another service (annotated with different codebase).


This precludes several scenarios such as for example "dynamic exporters" 
- exporters that are actually smart proxies.


Thanks,
Michal

Gregg Wonderly wrote:

I guess I am not sure then what you are trying to show with your example.

Under what case would the SpacePublisher be sent to another VM, and how is that 
different from normal SmartProxy deserialization?

Gregg


On Jan 23, 2017, at 2:39 PM, Michał Kłeczek (XPro Sp. z o. 
o.)  wrote:



Gregg Wonderly wrote:

michal.klec...@xpro.biz  
  >  wrote:

The use case and the ultimate test to implement is simple - have a

listener that publishes remote events to a JavaSpace acquired dynamically
from a lookup service:

class SpacePublisher implements RemoteEventListener, Serializable {
   private final JavaSpace space;
   public void notify(RemoteEvent evt) {
 space.write(createEntry(evt), ...);
   }
}

It is NOT possible to do currently. It requires non-hierarchical class

loading. It is not easy to solve. It would open a whole lot of
possibilities.

I am probably too ignorant to see it; What exactly is "NOT possible" with
the above use-case snippet?

With currently implemented PreferredClassProvider it is not possible to 
deserialize such an object graph.

This can happen, but what’s necessary is that the codebase of the 
SpacePublisher needs to include all the possible RemoteEvent classes, or the 
javaspace’s classpath has to include them.

I am not sure I understand.
The problem does not have anything to do with RemoteEvent (sub)classes. The 
issue is that SpacePublisher cannot be deserialized at all ( except one case 
when JavaSpace interface is available from context class loader and it is not 
marked as preferred in SpacePublisher code base).

Michal

Re: OSGi

[Gregg Wonderly]

I guess I am not sure then what you are trying to show with your example.

Under what case would the SpacePublisher be sent to another VM, and how is that 
different from normal SmartProxy deserialization?

Gregg

> On Jan 23, 2017, at 2:39 PM, Michał Kłeczek (XPro Sp. z o. o.) 
>  wrote:
> 
> 
> 
> Gregg Wonderly wrote:
>>> michal.klec...@xpro.biz  
>>>  > wrote:
 
> The use case and the ultimate test to implement is simple - have a
 listener that publishes remote events to a JavaSpace acquired dynamically
 from a lookup service:
> class SpacePublisher implements RemoteEventListener, Serializable {
>   private final JavaSpace space;
>   public void notify(RemoteEvent evt) {
> space.write(createEntry(evt), ...);
>   }
> }
> 
> It is NOT possible to do currently. It requires non-hierarchical class
 loading. It is not easy to solve. It would open a whole lot of
 possibilities.
 
 I am probably too ignorant to see it; What exactly is "NOT possible" with
 the above use-case snippet?
>>> With currently implemented PreferredClassProvider it is not possible to 
>>> deserialize such an object graph.
>> 
>> This can happen, but what’s necessary is that the codebase of the 
>> SpacePublisher needs to include all the possible RemoteEvent classes, or the 
>> javaspace’s classpath has to include them.   
> I am not sure I understand.
> The problem does not have anything to do with RemoteEvent (sub)classes. The 
> issue is that SpacePublisher cannot be deserialized at all ( except one case 
> when JavaSpace interface is available from context class loader and it is not 
> marked as preferred in SpacePublisher code base).
> 
> Michal

Re: OSGi

[Michał Kłeczek (XPro Sp. z o. o.)]

Gregg Wonderly wrote:

michal.klec...@xpro.biz > wrote:

The use case and the ultimate test to implement is simple - have a

listener that publishes remote events to a JavaSpace acquired dynamically
from a lookup service:

class SpacePublisher implements RemoteEventListener, Serializable {
   private final JavaSpace space;
   public void notify(RemoteEvent evt) {
 space.write(createEntry(evt), ...);
   }
}

It is NOT possible to do currently. It requires non-hierarchical class

loading. It is not easy to solve. It would open a whole lot of
possibilities.

I am probably too ignorant to see it; What exactly is "NOT possible" with
the above use-case snippet?

With currently implemented PreferredClassProvider it is not possible to 
deserialize such an object graph.


This can happen, but what’s necessary is that the codebase of the 
SpacePublisher needs to include all the possible RemoteEvent classes, or the 
javaspace’s classpath has to include them.

I am not sure I understand.
The problem does not have anything to do with RemoteEvent (sub)classes. 
The issue is that SpacePublisher cannot be deserialized at all ( except 
one case when JavaSpace interface is available from context class loader 
and it is not marked as preferred in SpacePublisher code base).


Michal

Re: OSGi

[Gregg Wonderly]

> On Jan 22, 2017, at 6:00 PM, Michał Kłeczek (XPro Sp. z o. o.) 
>  wrote:
> 
> Hi,
> 
> comments below.
> 
> Niclas Hedhman wrote:
>> On Mon, Jan 23, 2017 at 1:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
>> michal.klec...@xpro.biz > wrote:
>>> The use case and the ultimate test to implement is simple - have a
>> listener that publishes remote events to a JavaSpace acquired dynamically
>> from a lookup service:
>>> class SpacePublisher implements RemoteEventListener, Serializable {
>>>   private final JavaSpace space;
>>>   public void notify(RemoteEvent evt) {
>>> space.write(createEntry(evt), ...);
>>>   }
>>> }
>>> 
>>> It is NOT possible to do currently. It requires non-hierarchical class
>> loading. It is not easy to solve. It would open a whole lot of
>> possibilities.
>> 
>> I am probably too ignorant to see it; What exactly is "NOT possible" with
>> the above use-case snippet?
> With currently implemented PreferredClassProvider it is not possible to 
> deserialize such an object graph.

This can happen, but what’s necessary is that the codebase of the 
SpacePublisher needs to include all the possible RemoteEvent classes, or the 
javaspace’s classpath has to include them.   Jini doesn’t, dynamically, create 
codebase references which might flow back to the VM which sent the object, to 
let that VM send the correct class definition.  This has (and does still I 
believe) happen in other platforms.   I first saw this in ObjectSpace Voyager 
which appeared on the scene prior to Jini being open sourced.  

The idea of there being a free flowing graph of class definitions can create 
some conflicts that various timelines might cause different results to occur 
because of different versions of the class coming from different places.

Gregg

Re: OSGi

[Bharath Kumar]

Thanks all for the feedback.


At higher level, I see there are 2 kind of river service implementations.

   1.

   Service which doesn’t ask the client to download any code.(JERI)
   2.

   Service which ask the client to download code (smart services).


Here I describe what are all changes I made in POC for the first type of
service.

   1.

   I made an osgi bundle using the the river core classes as a system
   fragment. So all river classes will be loaded from framework class loader.

   2.

   I have set the following system properties while running the osgi
   container. Please refer the lookup.bndrun file.


   1.

  org.osgi.framework.bootdelegation=*
  2.

  org.osgi.framework.bundle.parent=framework

With the above 2 properties, we make sure that Framework class loader will
be parent of every bundle’s class loader. Core river classes will be
available to all bundles. So there will not be any problems when we
serialize/deserialize any of the river classes.

   1.

   As there is no downloaded code in this service implementation, we didn’t
   require class annotation. So service provider will not face any problems in
   the serialization of api and river classes. Service provider export the
   service from osgi bundle and register the proxy object without any problem.

   2.

   But this is not the case at client side. we have a problem in
   deserialization of the proxy object. Because we don’t know which osgi
   bundle has the service API classes for this proxy. I observed that
   PreferredClassProvider is already searching classes from the context
   classloader. So if we set the correct context classloader, this will not be
   a problem at client side.

   3.

   So I created a model where osgi bundles can request network service by
   registering ServiceTemplate object in osgi registry. As i mentioned in the
   previous mail, I created ServiceTemplateTracker which tracks these objects
   and remembers the bundle which has requested the network service. it
   manages river service discovery process using ServiceDiscoveryManager and
   LookupCache. In order to set the context classloader with correct bundle
   classloader, I patched the following classes.


   1.

  BasicInvocationDispatcher
  2.

  ServiceDiscoveryManager


This solved the deserialization of the proxy at client side.


I'll describe the second type of service in the next mail.


Thanks & Regards,

Bharath



On Mon, Jan 23, 2017 at 5:30 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> Hi,
>
> comments below.
>
> Niclas Hedhman wrote:
>
> On Mon, Jan 23, 2017 at 1:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)" 
>  wrote:
>
>
> I would say fully declarative approach in OSGI would be to only annotate
>
> with a package version range (and let the OSGI container do the resolution
> - it is designed to do it efficiently).
>
> Of course then we have a problem with classes that are not from any
>
> exported package but from internal bundle class path - then bundle id and
> version might be necessary.
>
> Then of course there is a question of classes from fragment bundles -
>
> this is totally unsolvable since AFAIK there is no way to get the fragment
> information based on the class loader of a class.
>
> Not that I grasp why it is needed, but you can get the Bundle information
> from the classloader, IF the class was loaded by OSGi. OSGi defines
> BundleClassLoader, so you simply cast the classloader to that, and with
> that you can get the Bundle and the BundleContext, which together should be
> able to give you all the meta info that you could need.
>
>
> It is needed to properly annotate a class during serialization.
> AFAIK in OSGI you can not find out which fragment (if any) was used to
> load a class.
> Based on the class loader you can get the bundle, but not the fragment.
>
> The concept of "download the proxy, both code and state" was quite novel
> in 1999 when I first heard of Jini. But I think it should be recognized
> that it both introduces a lot of security problems as well as not being the
> only way this can be done. For instance, the proxy could be an HTML page,
> which downloads JavaScript which binds into a sandbox provided. I think
> that the "serialized object" should not be a requirement eventually, and
> with that removed, the OSGi environment can help quite considerably aiding
> the dynamic nature of River.
>
> My view is different:
>
> 1. Without this "serialized object" approach there is no such a thing as
> River since there is nothing interesting and novel left.
> 2. Indeed - the "serialized object" approach is not popular... But my take
> on this is that it is because the concept has not been implemented
> correctly - both 

Re: OSGi

[Michał Kłeczek (XPro Sp. z o. o.)]

Hi,

comments below.

Niclas Hedhman wrote:

On Mon, Jan 23, 2017 at 1:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)"<
michal.klec...@xpro.biz>  wrote:


I would say fully declarative approach in OSGI would be to only annotate

with a package version range (and let the OSGI container do the resolution
- it is designed to do it efficiently).

Of course then we have a problem with classes that are not from any

exported package but from internal bundle class path - then bundle id and
version might be necessary.

Then of course there is a question of classes from fragment bundles -

this is totally unsolvable since AFAIK there is no way to get the fragment
information based on the class loader of a class.

Not that I grasp why it is needed, but you can get the Bundle information
from the classloader, IF the class was loaded by OSGi. OSGi defines
BundleClassLoader, so you simply cast the classloader to that, and with
that you can get the Bundle and the BundleContext, which together should be
able to give you all the meta info that you could need.


It is needed to properly annotate a class during serialization.
AFAIK in OSGI you can not find out which fragment (if any) was used to 
load a class.

Based on the class loader you can get the bundle, but not the fragment.

The concept of "download the proxy, both code and state" was quite 
novel in 1999 when I first heard of Jini. But I think it should be 
recognized that it both introduces a lot of security problems as well 
as not being the only way this can be done. For instance, the proxy 
could be an HTML page, which downloads JavaScript which binds into a 
sandbox provided. I think that the "serialized object" should not be a 
requirement eventually, and with that removed, the OSGi environment 
can help quite considerably aiding the dynamic nature of River. 

My view is different:

1. Without this "serialized object" approach there is no such a thing as 
River since there is nothing interesting and novel left.
2. Indeed - the "serialized object" approach is not popular... But my 
take on this is that it is because the concept has not been implemented 
correctly - both in terms of security and in terms of class loading.


As Peter observed, Pax URL allows a whole bunch of URL schemes, which 
you could be annotated in the serialized objects, just like URL 
codebases are today. For instance, Maven "coordinates" could be in the 
annotations and OSGi loads bundles on-demand. Paremus also implemented 
a "bundle garbage collector" in some manner, which unloaded unused 
bundles eventually. Furthermore, there are defined hooks in OSGi for 
the resolution of service registration and service lookup, which I 
think River should exploit. There seems to be a huge complementary 
intersection right there. 

There are no hooks for _class_ resolution - that's what is needed.


The use case and the ultimate test to implement is simple - have a

listener that publishes remote events to a JavaSpace acquired dynamically
from a lookup service:

class SpacePublisher implements RemoteEventListener, Serializable {
   private final JavaSpace space;
   public void notify(RemoteEvent evt) {
 space.write(createEntry(evt), ...);
   }
}

It is NOT possible to do currently. It requires non-hierarchical class

loading. It is not easy to solve. It would open a whole lot of
possibilities.

I am probably too ignorant to see it; What exactly is "NOT possible" with
the above use-case snippet?
With currently implemented PreferredClassProvider it is not possible to 
deserialize such an object graph.


Thanks,
Michal

Re: OSGi

[Niclas Hedhman]

On Mon, Jan 23, 2017 at 1:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:

> I would say fully declarative approach in OSGI would be to only annotate
with a package version range (and let the OSGI container do the resolution
- it is designed to do it efficiently).
> Of course then we have a problem with classes that are not from any
exported package but from internal bundle class path - then bundle id and
version might be necessary.
> Then of course there is a question of classes from fragment bundles -
this is totally unsolvable since AFAIK there is no way to get the fragment
information based on the class loader of a class.

Not that I grasp why it is needed, but you can get the Bundle information
from the classloader, IF the class was loaded by OSGi. OSGi defines
BundleClassLoader, so you simply cast the classloader to that, and with
that you can get the Bundle and the BundleContext, which together should be
able to give you all the meta info that you could need.

> And the main issue with this approach IMHO is that it requires a central
authority that governs the naming and versioning of bundles.

It is rather rare that Bundle management is needed. The OBR (OSGi Bundle
Repository) spec could be leveraged to resolve "package name+version" to
bundle location, and deploying an OBR capable service on a network is
relatively simple (serve a XML over HTTP).

> Approach 2 in OSGI would require annotating a class not with a bundle but
with a piece of information that would allow
> the client to download the _BundleWiring_ of the proxy - it unambiguously
specifies the class loader graph that is
> required to be recreated by the client to deserialize an object..
>
> When I tried to implement it - it appeared to me that the main issue is
that it simply makes the whole OSGI with its declarative
> dependency resolution moot - we need to totally bypass it to transfer
objects between containers anyway. So the only thing
> we actually would use from an OSGI container is its capability of
non-hierarchical class loading.

The concept of "download the proxy, both code and state" was quite novel in
1999 when I first heard of Jini. But I think it should be recognized that
it both introduces a lot of security problems as well as not being the only
way this can be done. For instance, the proxy could be an HTML page, which
downloads JavaScript which binds into a sandbox provided. I think that the
"serialized object" should not be a requirement eventually, and with that
removed, the OSGi environment can help quite considerably aiding the
dynamic nature of River.

> One step towards solving the above issues is to implement the idea of
code base annotations being objects
> implementing a well known interface - that would at least allow us to
abstract away from the exact format of
> the annotation data. But I do not have a clear idea on how to solve other
OSGI integration issues.

As Peter observed, Pax URL allows a whole bunch of URL schemes, which you
could be annotated in the serialized objects, just like URL codebases are
today. For instance, Maven "coordinates" could be in the annotations and
OSGi loads bundles on-demand. Paremus also implemented a "bundle garbage
collector" in some manner, which unloaded unused bundles eventually.

Furthermore, there are defined hooks in OSGi for the resolution of service
registration and service lookup, which I think River should exploit. There
seems to be a huge complementary intersection right there.

> The use case and the ultimate test to implement is simple - have a
listener that publishes remote events to a JavaSpace acquired dynamically
from a lookup service:
>
> class SpacePublisher implements RemoteEventListener, Serializable {
>   private final JavaSpace space;
>   public void notify(RemoteEvent evt) {
> space.write(createEntry(evt), ...);
>   }
> }
>
> It is NOT possible to do currently. It requires non-hierarchical class
loading. It is not easy to solve. It would open a whole lot of
possibilities.

I am probably too ignorant to see it; What exactly is "NOT possible" with
the above use-case snippet?


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

Re: OSGi

[Niclas Hedhman]

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 @Component(iimmediate=yes) 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  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
>&

Re: OSGi

[Michał Kłeczek (XPro Sp. z o. o.)]

Hi,

Bharath Kumar wrote:


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


If it only was that easy it would have been done a long time ago :)

The question "how to annotate a class" is difficult to answer.
I can see two approaches:

1. Declarative specification of _requirements_ to successfully 
deserialize an object (ie. a proxy). The client must have all the 
necessary mechanisms in place to resolve, download and install anything 
required to satisfy these requirements.


2. Fully specifying what code to download (and ideally - how). This is 
the approach of River at this moment. The client simply uses provided 
URLs to create an URLClassLoader (of course adding security and 
preferred resources but in general that's how it works)


Annotating with bundle id and version is actually half way - it neither 
is self contained and sufficient to download code and it does not allow 
the client to fully decide how the requirement should be satisfied.


And since the client bundle and the service bundle might be resolved 
differently by the container - it may lead to all sorts of pseudorandom 
class cast exceptions.


I would say fully declarative approach in OSGI would be to only annotate 
with a package version range (and let the OSGI container do the 
resolution - it is designed to do it efficiently).
Of course then we have a problem with classes that are not from any 
exported package but from internal bundle class path - then bundle id 
and version might be necessary.
Then of course there is a question of classes from fragment bundles - 
this is totally unsolvable since AFAIK there is no way to get the 
fragment information based on the class loader of a class.


And the main issue with this approach IMHO is that it requires a central 
authority that governs the naming and versioning of bundles.


Approach 2 in OSGI would require annotating a class not with a bundle 
but with a piece of information that would allow the client to download 
the _BundleWiring_ of the proxy - it unambiguously specifies the class 
loader graph that is required to be recreated by the client to 
deserialize an object..


When I tried to implement it - it appeared to me that the main issue is 
that it simply makes the whole OSGI with its declarative dependency 
resolution moot - we need to totally bypass it to transfer objects 
between containers anyway. So the only thing we actually would use from 
an OSGI container is its capability of non-hierarchical class loading.


One step towards solving the above issues is to implement the idea of 
code base annotations being objects implementing a well known interface 
- that would at least allow us to abstract away from the exact format of 
the annotation data. But I do not have a clear idea on how to solve 
other OSGI integration issues.


The use case and the ultimate test to implement is simple - have a 
listener that publishes remote events to a JavaSpace acquired 
dynamically from a lookup service:


class SpacePublisher implements RemoteEventListener, Serializable {
  private final JavaSpace space;
  public void notify(RemoteEvent evt) {
space.write(createEntry(evt), ...);
  }
}

It is NOT possible to do currently. It requires non-hierarchical class 
loading. It is not easy to solve. It would open a whole lot of 
possibilities.


My 2 cents :)
Michal

Re: OSGi

[Peter]

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 pr

Re: OSGi

[Bharath Kumar]

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

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

Re: OSGi

[Peter]

Thanks Bharath, 

LookupDiscoveryManager allows "this" to escape during construction, which is 
why it's a stateless final object, it's superclass 
AbstractLookupDiscoveryManager contains final fields, these are frozen prior to 
publication.  Subclasses of LookupDiscoveryManager cannot safely use final 
fields, they could potentially use non-final fields, but any calls that access 
those fields must dereference the LookupDiscoveryManager via safe publication 
idioms if shared among threads.

AbstractLookupDiscoveryManager could be made public for extension as it doesn't 
allow "this" to escape during construction.  However a better solution for 
client code, would be to implement the interfaces; DiscoveryManagement, 
DiscoveryGroupManagement, DiscoveryLocatorManagement and encapsulate 
LookupDiscoveryManagement instead.   I might just fix that in Rio and 
contribute a patch, as that change will still be compatible with earlier River 
& Jini versions.

Ironically I also made LookupDiscoveryManager non final in JGDMS to support Rio 
and created a com.sun.jini compatibility layer.

Versions of River prior to 3.0 are designed for the original Java memory model. 
 Unfortunately the earlier versions are not easily modified, minor changes 
often caused unexpected test failures.

Cheers,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Bharath Kumar 
Sent: 21/01/2017 12:09:04 am
To: dev@river.apache.org
Subject: Re: OSGi

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  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  
> 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.Componentgroovy 
> 
> net.jini.config.GroovyConfig.groovy 
> 
> 
> 
> Thanks & Regards, 
> 
> Bharath 
> 
> 
> 
> 
> 
> On Fri, Jan 20, 2017 at 3:47 PM, Bharath Kumar  
> 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  > 
> > 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  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 - Riv

Re: OSGi

[Bharath Kumar]

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

Re: OSGi

[Peter]

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

Re: OSGi

[Bharath Kumar]

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 
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 
> 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 > > 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.river.lookup 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  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 
>>>> 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 th

Re: OSGi

[Bharath Kumar]

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 
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.river.lookup
> 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  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 
>> 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 resolve class
>> loading issues. I have excluded other services like transaction services,
>> Java space services.
>>
>> I am using eclipse and bndtools for the development. I am ready to share
>> these 3 bundles to this great community.
>>
>> Thanks & Regards,
>> Bharath
>>
>>
>>
>>
>> On Jan 19, 2017 8:55 AM, "Peter"  wrote:
>>
>> Thanks Nic & Richard, will follow up your leads.
>>
>> Peter.
>>
>> Sent from my Samsung device.
>>
>>   Include original message
>>  Original message 
>> From: Niclas Hedhman 
>> 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
>> always a question
>> of hiding internal packages/classes. Instead of aiming for
>> running '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 relatively 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
&g

Re: OSGi

[Bharath Kumar]

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.river.lookup
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  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 
> 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 manager, export
> remote services.
> 3. Lookup service.
>
> I made some minor changes to River classes (10 Classes) to resolve class
> loading issues. I have excluded other services like transaction services,
> Java space services.
>
> I am using eclipse and bndtools for the development. I am ready to share
> these 3 bundles to this great community.
>
> Thanks & Regards,
> Bharath
>
>
>
>
> On Jan 19, 2017 8:55 AM, "Peter"  wrote:
>
> Thanks Nic & Richard, will follow up your leads.
>
> Peter.
>
> Sent from my Samsung device.
>
>   Include original message
>  Original message 
> From: Niclas Hedhman 
> 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 always a question
> of hiding internal packages/classes. Instead of aiming for running '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 relatively 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 add 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 manifest entry's for
> > OSGi, as the use of service provider style abstractions within 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 Energy for Java
>
>

Re: OSGi

[Peter]

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 
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 manager, export 
remote services. 
3. Lookup service. 

I made some minor changes to River classes (10 Classes) to resolve class 
loading issues. I have excluded other services like transaction services, 
Java space services. 

I am using eclipse and bndtools for the development. I am ready to share 
these 3 bundles to this great community. 

Thanks & Regards, 
Bharath 




On Jan 19, 2017 8:55 AM, "Peter"  wrote: 

Thanks Nic & Richard, will follow up your leads. 

Peter. 

Sent from my Samsung device. 

  Include original message 
 Original message  
From: Niclas Hedhman  
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 always a question 
of hiding internal packages/classes. Instead of aiming for running '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 relatively 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 add 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 manifest entry's for 
> OSGi, as the use of service provider style abstractions within 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 Energy for Java 

Re: OSGi

[Bharath Kumar]

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 manager, export
remote services.
3. Lookup service.

I made some minor changes to River classes (10 Classes) to resolve class
loading issues. I have excluded other services like transaction services,
Java space services.

I am using eclipse and bndtools for the development. I am ready to share
these 3 bundles to this great community.

Thanks & Regards,
Bharath




On Jan 19, 2017 8:55 AM, "Peter"  wrote:

Thanks Nic & Richard, will follow up your leads.

Peter.

Sent from my Samsung device.

  Include original message
 Original message 
From: Niclas Hedhman 
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 always a question
of hiding internal packages/classes. Instead of aiming for running '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 relatively 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 add 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 manifest entry's for
> OSGi, as the use of service provider style abstractions within 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 Energy for Java

Re: OSGi

[Peter]

Thanks Nic & Richard, will follow up your leads.

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Niclas Hedhman 
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 always a question 
of hiding internal packages/classes. Instead of aiming for running '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 relatively 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 add 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 manifest entry's for 
> OSGi, as the use of service provider style abstractions within 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 Energy for Java 

Re: OSGi

[Niclas Hedhman]

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 always a question
of hiding internal packages/classes. Instead of aiming for running '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 relatively 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 add 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 manifest entry's for
> OSGi, as the use of service provider style abstractions within 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 Energy for Java

Re: OSGi

[Richard Nicholson]

Peter, 

If you have any general OSGi queries try the osgi-dev mail list - the folks 
there are very willing to help with general OSGi questions. The link is 
https://mail.osgi.org/mailman/listinfo/osgi-dev 
<https://mail.osgi.org/mailman/listinfo/osgi-dev>

Best Wishes 

Richard 


> On 18 Jan 2017, at 03:18, Peter Firmstone  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 add 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 manifest entry's for 
> OSGi, as the use of service provider style abstractions within 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.
>  

OSGi

[Peter Firmstone]

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 add 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 manifest entry's for OSGi, 
as the use of service provider style abstractions within 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.