Re: OSGi Bundles for services

2017-02-24 Thread Peter 

True, better to start small and grow, just looking for some buy in, 's all.

Cheers,

Peter.

On 24/02/2017 9:43 AM, Niclas Hedhman wrote:

I am sure there a lot of devils in the details here, but I think that you
have something that is workable, and better to get something smaller (but
evolvable) out the door for people to try than to spend eternity debating
the better approach.

Cheers
Niclas

On Fri, Feb 24, 2017 at 7:14 AM, Peter  wrote:


When you think about classes with annotations in this environment, it also
means that classes at the client
may not return to the originating ClassLoader as boomerangs, unless
they're resolved by a common imported package by the proxy bundle.  When
the boomerang returns it will be loaded in a PreferredClassLoader which has
the proxy as the parent ClassLoader in teh client instead of the
originating ClassLoader.

So if the client registered a listener with a service that remotely
filtered or sent events as batches, the client would have to view the
results via a common api interface.  There would of course be no codebase
annotation losses, the point is objects may not return to their originating
loader, so it would seem best to avoid using codebase annotations in OSGi
unless a developer is very familiar with ClassLoaders etc.

It might be possible to register ClassLoader's with their codebase
annotation locally and associate them with proxy ClassLoaders, via a lookup
list in PreferredClassProvider, allowing boomerangs to return to the
correct ClassLoader, while also allowing PreferredClassProvider to discover
annotations.  The annotation itself doesn't need to be a reference to the
Bundle, just a suitable list of jar files that would provide the same
classes.

The thought exercise is interesting in any case.  Sometimes though,
simpler is better, it may be preferable to see how developers cope without
the bells and whistles first as this is far easier to debug and less
subject to problems, for some minor sacrifices in capability.

Regards,

Peter.


On 24/02/2017 8:52 AM, Peter wrote:


In case you're wondering why I've created bundles / modules
structured like below, if the endpoint was deserialized into the
service implementation bundle instead of the proxy bundle,
it may not be able to see deserialized classes from the proxy bundle's
  transitive imports.

In effect the proxy bundle becomes the equivalent of the application
ClassLoader at each endpoint.

So any annotated classes will be loaded into PreferredClassLoader's
that have the proxy bundle as the parent ClassLoader.  Any classes in
these ClassLoaders would have a very limited view, they could only
utilise packages imported by the proxy bundle, allowing the proxy
to limit available classes very easily, similar to a sandbox.

For example Mercury's proxy would allow packages in the java.* namespace
plus classes from any of the following packages:

Import-Package: net.jini.admin;version="[3.0,4)",net.jini.core.constra
  int;version="[3.0,4)",net.jini.core.discovery;version="[3.0,4)",net.j
  ini.core.entry;version="[3.0,4)",net.jini.core.event;version="[3.0,4)
  ",net.jini.core.lease;version="[3.0,4)",net.jini.event;version="[3.0,
  4)",net.jini.export;version="[3.0,4)",net.jini.id;version="[3.0,4)",n
  et.jini.io;version="[3.0,4)",net.jini.lookup;version="[3.0,4)",net.ji
  ni.security;version="[3.0,4)",net.jini.security.proxytrust;version="[
  3.0,4)",org.apache.river.admin;version="[3.0,4)",org.apache.river.api
  .io;version="[3.0,4)",org.apache.river.landlord;version="[3.0,4)",org
  .apache.river.proxy;version="[3.0,4)"

DownloadPermission can be used to prevent marshalling of downloaded
objects.

However the service could advertise available resouces via an Entry.

Cheers,

Peter.

On 23/02/2017 4:13 PM, Peter wrote:


Hmm,  ASCII keeps getting scrubbed, so here it is:


   SERVER JVM


 __
|  |
|  Service |
|  API Bundle  |
|__|
   |
   |
Imports
  API
Packages
   |
   |
     __|___
||   Imports packages  |  |
|   Service Bundle   |<| Proxy Bundle |---EP
|   Implements   |  from proxy |__|   |
|   Proxy API||
||

Re: OSGi Bundles for services

2017-02-23 Thread Peter 
When you think about classes with annotations in this environment, it 
also means that classes at the client
may not return to the originating ClassLoader as boomerangs, unless 
they're resolved by a common imported package by the proxy bundle.  When 
the boomerang returns it will be loaded in a PreferredClassLoader which 
has the proxy as the parent ClassLoader in teh client instead of the 
originating ClassLoader.


So if the client registered a listener with a service that remotely 
filtered or sent events as batches, the client would have to view the 
results via a common api interface.  There would of course be no 
codebase annotation losses, the point is objects may not return to their 
originating loader, so it would seem best to avoid using codebase 
annotations in OSGi unless a developer is very familiar with 
ClassLoaders etc.


It might be possible to register ClassLoader's with their codebase 
annotation locally and associate them with proxy ClassLoaders, via a 
lookup list in PreferredClassProvider, allowing boomerangs to return to 
the correct ClassLoader, while also allowing PreferredClassProvider to 
discover annotations.  The annotation itself doesn't need to be a 
reference to the Bundle, just a suitable list of jar files that would 
provide the same classes.


The thought exercise is interesting in any case.  Sometimes though, 
simpler is better, it may be preferable to see how developers cope 
without the bells and whistles first as this is far easier to debug and 
less subject to problems, for some minor sacrifices in capability.


Regards,

Peter.

On 24/02/2017 8:52 AM, Peter wrote:

In case you're wondering why I've created bundles / modules
structured like below, if the endpoint was deserialized into the
service implementation bundle instead of the proxy bundle,
it may not be able to see deserialized classes from the proxy bundle's
 transitive imports.

In effect the proxy bundle becomes the equivalent of the application
ClassLoader at each endpoint.

So any annotated classes will be loaded into PreferredClassLoader's
that have the proxy bundle as the parent ClassLoader.  Any classes in
these ClassLoaders would have a very limited view, they could only
utilise packages imported by the proxy bundle, allowing the proxy
to limit available classes very easily, similar to a sandbox.

For example Mercury's proxy would allow packages in the java.* namespace
plus classes from any of the following packages:

Import-Package: net.jini.admin;version="[3.0,4)",net.jini.core.constra
 int;version="[3.0,4)",net.jini.core.discovery;version="[3.0,4)",net.j
 ini.core.entry;version="[3.0,4)",net.jini.core.event;version="[3.0,4)
 ",net.jini.core.lease;version="[3.0,4)",net.jini.event;version="[3.0,
 4)",net.jini.export;version="[3.0,4)",net.jini.id;version="[3.0,4)",n
 et.jini.io;version="[3.0,4)",net.jini.lookup;version="[3.0,4)",net.ji
 ni.security;version="[3.0,4)",net.jini.security.proxytrust;version="[
 3.0,4)",org.apache.river.admin;version="[3.0,4)",org.apache.river.api
 .io;version="[3.0,4)",org.apache.river.landlord;version="[3.0,4)",org
 .apache.river.proxy;version="[3.0,4)"

DownloadPermission can be used to prevent marshalling of downloaded 
objects.


However the service could advertise available resouces via an Entry.

Cheers,

Peter.

On 23/02/2017 4:13 PM, Peter wrote:

Hmm,  ASCII keeps getting scrubbed, so here it is:


  SERVER JVM


__
   |  |
   |  Service |
   |  API Bundle  |
   |__|
  |
  |
   Imports
 API
   Packages
  |
  |
    __|___
||   Imports packages  |  |
|   Service Bundle   |<| Proxy Bundle |---EP
|   Implements   |  from proxy |__|   |
|   Proxy API||
|||
  |
  |
  |
  |
  |
  N
  E

Re: OSGi Bundles for services

2017-02-23 Thread Peter 

In case you're wondering why I've created bundles / modules
structured like below, if the endpoint was deserialized into the
service implementation bundle instead of the proxy bundle,
it may not be able to see deserialized classes from the proxy bundle's
 transitive imports.

In effect the proxy bundle becomes the equivalent of the application
ClassLoader at each endpoint.

So any annotated classes will be loaded into PreferredClassLoader's
that have the proxy bundle as the parent ClassLoader.  Any classes in
these ClassLoaders would have a very limited view, they could only
utilise packages imported by the proxy bundle, allowing the proxy
to limit available classes very easily, similar to a sandbox.

For example Mercury's proxy would allow packages in the java.* namespace
plus classes from any of the following packages:

Import-Package: net.jini.admin;version="[3.0,4)",net.jini.core.constra
 int;version="[3.0,4)",net.jini.core.discovery;version="[3.0,4)",net.j
 ini.core.entry;version="[3.0,4)",net.jini.core.event;version="[3.0,4)
 ",net.jini.core.lease;version="[3.0,4)",net.jini.event;version="[3.0,
 4)",net.jini.export;version="[3.0,4)",net.jini.id;version="[3.0,4)",n
 et.jini.io;version="[3.0,4)",net.jini.lookup;version="[3.0,4)",net.ji
 ni.security;version="[3.0,4)",net.jini.security.proxytrust;version="[
 3.0,4)",org.apache.river.admin;version="[3.0,4)",org.apache.river.api
 .io;version="[3.0,4)",org.apache.river.landlord;version="[3.0,4)",org
 .apache.river.proxy;version="[3.0,4)"

DownloadPermission can be used to prevent marshalling of downloaded objects.

However the service could advertise available resouces via an Entry.

Cheers,

Peter.

On 23/02/2017 4:13 PM, Peter wrote:

Hmm,  ASCII keeps getting scrubbed, so here it is:


  SERVER JVM


__
   |  |
   |  Service |
   |  API Bundle  |
   |__|
  |
  |
   Imports
 API
   Packages
  |
  |
    __|___
||   Imports packages  |  |
|   Service Bundle   |<| Proxy Bundle |---EP
|   Implements   |  from proxy |__|   |
|   Proxy API||
|||
  |
  |
  |
  |
  |
  N
  E
   CLIENT JVM T
  W
  O
__R
   |  |   K
||   Imports packages  |  Service |   |
|  Management Agent  |<|  API Bundle  |   |
|  Discovers &   |   from API  |__|   |
|  Registers service ||   |
|||   |
   Imports|
 API  |
   Packages   |
  |   |
  |   |
__|___|
   |  |   |
   | Proxy Bundle |---EP
   |__|



Note other package imports omitted for clarity.

On 23/02/2017 3:26 PM, Peter wrote:
I've attached some ASCII of the relationship between server and 
client jvm bundles.


The ClassLoader at the server is set using the invocation layer 
factory (a configuration item).


The client ClassLoader is determined during delayed unmarshalling and 
smart proxy

Re: OSGi Bundles for services

2017-02-22 Thread Peter 

Hmm,  ASCII keeps getting scrubbed, so here it is:


  SERVER JVM


__
   |  |
   |  Service |
   |  API Bundle  |
   |__|
  |
  |
   Imports
 API
   Packages
  |
  |
    __|___
||   Imports packages  |  |
|   Service Bundle   |<| Proxy Bundle |---EP
|   Implements   |  from proxy |__|   |
|   Proxy API||
|||
  |
  |
  |
  |
  |
  N
  E
   CLIENT JVM T
  W
  O
__R
   |  |   K
||   Imports packages  |  Service |   |
|  Management Agent  |<|  API Bundle  |   |
|  Discovers &   |   from API  |__|   |
|  Registers service ||   |
|||   |
   Imports|
 API  |
   Packages   |
  |   |
  |   |
__|___|
   |  |   |
   | Proxy Bundle |---EP
   |__|



Note other package imports omitted for clarity.

On 23/02/2017 3:26 PM, Peter wrote:
I've attached some ASCII of the relationship between server and client 
jvm bundles.


The ClassLoader at the server is set using the invocation layer 
factory (a configuration item).


The client ClassLoader is determined during delayed unmarshalling and 
smart proxy bundle provisioning.


This ensures that deserialization at each endpoint has a compatible 
view of classes (as recently discussed on osgi-dev).


It's important at this time to distinguish between remote objects and 
remote services, registered with a lookup service.


A remote service must have a proxy bundle for OSGi.  The proxy bundle 
manifest determines requirements and wiring to package import 
versions.  This includes dynamic proxy based services.


For arguments sake, a remote object becomes a remote service when it 
is registered with a lookup service.


A remote object isn't registered with a lookup service.  Listeners are 
typically remote objects.  In OSGi, it is advisable for remote objects 
to be dynamic proxy's without a codebase.  Remote Object proxy's will 
be deserialized into the remote endpoint's nominated ClassLoader.  For 
example, if it is transferred via a service, the remote object's 
dynamic proxy stub will be loaded into the service's proxy bundle 
ClassLoader in the server jvm.


As Nic pointed out earlier, Bundle ClassLoader's are not instances of 
URLClassLoader and lack codebase annotations as a result.


With the above rules in place, there is no need to create a custom 
RMIClassLoaderSpi specific to OSGi.


With the above rules in place, it does open up an opportunity to use a 
remote object (eg a listener) with a conventional codebase as Mic had 
requested.   This would use the PreferredClassProvider infrastructure, 
so the remote object proxy PreferredClassLoader would utilise the 
services server jvm proxy bundle ClassLoader as it's parent.  This 
style of remote object should not be registered as a remote service.


I would probably discourage this use

Re: OSGi Bundles for services

2017-02-22 Thread Peter 


Sent from my Samsung device.
 
  Include original message
 Original message 
From: Peter <j...@zeus.net.au>
Sent: 23/02/2017 03:26:15 pm
To: dev@river.apache.org <dev@river.apache.org>
Subject: OSGi Bundles for services

I've attached some ASCII of the relationship between server and client jvm 
bundles.

The ClassLoader at the server is set using the invocation layer factory (a 
configuration item).

The client ClassLoader is determined during delayed unmarshalling and smart 
proxy bundle provisioning.

This ensures that deserialization at each endpoint has a compatible view of 
classes (as recently discussed on osgi-dev).

It's important at this time to distinguish between remote objects and remote 
services, registered with a lookup service.

A remote service must have a proxy bundle for OSGi.  The proxy bundle manifest 
determines requirements and wiring to package import versions.  This includes 
dynamic proxy based services.

For arguments sake, a remote object becomes a remote service when it is 
registered with a lookup service.

A remote object isn't registered with a lookup service.  Listeners are 
typically remote objects.  In OSGi, it is advisable for remote objects to be 
dynamic proxy's without a codebase.  Remote Object proxy's will be deserialized 
into the remote endpoint's nominated ClassLoader.  For example, if it is 
transferred via a service, the remote object's dynamic proxy stub will be 
loaded into the service's proxy bundle ClassLoader in the server jvm.

As Nic pointed out earlier, Bundle ClassLoader's are not instances of 
URLClassLoader and lack codebase annotations as a result.

With the above rules in place, there is no need to create a custom 
RMIClassLoaderSpi specific to OSGi.

With the above rules in place, it does open up an opportunity to use a remote 
object (eg a listener) with a conventional codebase as Mic had requested.   
This would use the PreferredClassProvider infrastructure, so the remote object 
proxy PreferredClassLoader would utilise the services server jvm proxy bundle 
ClassLoader as it's parent.  This style of remote object should not be 
registered as a remote service.

I would probably discourage this use case, except for advanced users.

I think we need to make a distinction between remote services and remote 
objects for OSGi.

This is a very practical solution for OSGi.

Regards,

Peter.


Sent from my Samsung device.