Re: OSGi

hat we need to solve with architecture > evolution. > > All of the things that I’ve tied to push into the Jini community as > solutions have been meant to start conversations and show where I’ve > encountered friction which I felt software changes to the platform could > allevia

Re: OSGi

> On Feb 4, 2017, at 5:09 AM, Niclas Hedhman wrote: > > see below > > On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < > michal.klec...@xpro.biz> wrote: >> In the end all of the arguments against Java Object Serialization boil > down to: >> "It is easy

Re: OSGi

> On Feb 4, 2017, at 4:21 AM, Michał Kłeczek (XPro Sp. z o. o.) > wrote: > > Once you transfer the code with your data - the issue of code version > synchronization disappears, doesn't it? > It also makes the wire data format irrelevant. At least for "short lived >

Re: OSGi

rly <ge...@cox.net> wrote: > >> >>> On Feb 3, 2017, at 8:43 PM, Niclas Hedhman <nic...@hedhman.org> wrote: >>> >>> On Fri, Feb 3, 2017 at 12:23 PM, Peter <j...@zeus.net.au> wrote: >>> >>>> >>>> No serializa

Re: Serialization Formats, Previously: OSGi

onfuse users > (in our case programmers) and in the end people loose interest. > > I am not a big fan of Java containers - be it JEE or any other (OSGI > included) > The industry seems to understand they are a dead end - escpecially in the > age of Docker etc - and is moving away fro

Re: OSGi

On Sun, Feb 5, 2017 at 1:23 AM, Gregg Wonderly wrote: > Okay, rant completed. Gregg, you are probably right about the web, endless problems and sheer will-power has made it to apparently work. > What other details of Jini vs the Web are problem areas > to you? What makes the

Re: Serialization Formats, Previously: OSGi

different interesting scenarios. Partial solutions are worse than lack of solutions - they confuse users (in our case programmers) and in the end people loose interest. I am not a big fan of Java containers - be it JEE or any other (OSGI included) The industry seems to understand they are

Re: OSGi

“The web” is, in fact, an example of a mobile code platform different from Jini. It doesn’t work better and in many cases I find it worse than Jini. It has the same problems set we have. The JSON or XML or whatever “data” you send must be in sync with the Javascript running in the browser.

Re: OSGi

an explore how the annotation can move from being a URL, which you could recognize and still use, but substitute your own indicator for another platform such as a maven or OSGi targeted codebase. Thus, you can still use the annotation, but use it to specify the type of stream instead of what t

Re: OSGi

recognize and still use, but substitute your own indicator for another platform such as a maven or OSGi targeted codebase. Thus, you can still use the annotation, but use it to specify the type of stream instead of what to download via HTTP. Gregg > On Feb 4, 2017, at 2:02 AM, Michał Kłec

Re: Serialization Formats, Previously: OSGi

or butcher your neighbor... It is all about the constraints, something that few developers are willing to admit that makes our work better. As for the "leasable and you have..."; The problem is that you are probably wrong on that front too, like the OSGi community have learned the hard way. The

Re: OSGi

Comments below. Niclas Hedhman wrote: see below On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)"< michal.klec...@xpro.biz> wrote: Once you transfer the code with your data - the issue of code version synchronization disappears, doesn't it? It also makes the wire data

Serialization Formats, Previously: OSGi

I think we're getting off topic, can we create a new thread, as we're no longer discussing OSGi, but the virtues of various serialization formats? Cheers, Peter. On 4/02/2017 9:09 PM, Niclas Hedhman wrote: see below On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z

Re: OSGi

Oh, well that is not "Serialization" per se... No wonder i didn't get it. On Sat, Feb 4, 2017 at 7:20 PM, Peter wrote: > On 4/02/2017 9:09 PM, Niclas Hedhman wrote: > >> >> but rather with the APIs - it is inherently blocking by design. >>> >> I am not sure I understand what

Re: OSGi

On 4/02/2017 9:09 PM, Niclas Hedhman wrote: but rather with the APIs - it is inherently blocking by design. I am not sure I understand what you mean by that. He means the client thread that makes the remote call blocks waiting for the remote end to process the request and respond.

Re: OSGi

see below On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < michal.klec...@xpro.biz> wrote: > Once you transfer the code with your data - the issue of code version synchronization disappears, doesn't it? > It also makes the wire data format irrelevant. At least for "short

Re: OSGi

Once you transfer the code with your data - the issue of code version synchronization disappears, doesn't it? It also makes the wire data format irrelevant. At least for "short lived serialized states". I fail to understand how JSON or XML changes anything here. In the end all of the

Re: OSGi

Niclas On Sat, Feb 4, 2017 at 3:35 PM, Gregg Wonderly <ge...@cox.net> wrote: > > > On Feb 3, 2017, at 8:43 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > > > > On Fri, Feb 3, 2017 at 12:23 PM, Peter <j...@zeus.net.au> wrote: > > > >> >

Re: OSGi

The latter... It works rather well for JavaScript in web browsers. I think that is the most interesting "mobile code" platform to review as a starting point. On Sat, Feb 4, 2017 at 2:54 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < michal.klec...@xpro.biz> wrote: > Are you opposing the whole idea

Re: OSGi

My annotated streams replace codebase resolution with object based one (ie - not using RMIClassLoader). Michal Gregg Wonderly wrote: Why specific things do you want your AnnotatedStream to provide? Gregg

Re: OSGi

ream implementations I must basically rewrite the invocation layer) > > Thanks, > Michal > > > Peter wrote: >> FYI. JERI != Java RMI. >> >> There's no reason these layers couldn't be provided as OSGi services and >> selected from the service registry either. &g

Re: OSGi

as OSGi services and selected from the service registry either. Cheers, Peter. Protocol Stack The Jini ERI architecture has a protocol stack with three layers as shown in the following table, with interfaces representing the abstractions of each layer on the client side and the server

Re: OSGi

FYI. JERI != Java RMI. There's no reason these layers couldn't be provided as OSGi services and selected from the service registry either. Cheers, Peter. Protocol Stack The Jini ERI architecture has a protocol stack with three layers as shown in the following table, with interfaces

Re: OSGi

Are you opposing the whole idea of sending data and code (or instructions how to download it) bundled together? (the spec) Or just the way how it is done in Java today. (the impl) If it is the first - we are in an absolute disagreement. If the second - I agree wholeheartedly. Thanks, Michal

Re: OSGi

12:43 PM, Niclas Hedhman wrote: On Fri, Feb 3, 2017 at 12:23 PM, Peter<j...@zeus.net.au> wrote: No serialization or Remote method invocation framework currently supports OSGi very well, one that works well and can provide security might gain a lot of new interest from that user ba

Re: OSGi

: >> >> No serialization or Remote method invocation framework currently supports >>> OSGi very well, one that works well and can provide security might gain a >>> lot of new interest from that user base. >>> >> >> What do you mean by this? Jackson's O

Re: OSGi

On 4/02/2017 12:43 PM, Niclas Hedhman wrote: On Fri, Feb 3, 2017 at 12:23 PM, Peter<j...@zeus.net.au> wrote: No serialization or Remote method invocation framework currently supports OSGi very well, one that works well and can provide security might gain a lot of new interest from tha

Re: OSGi

On Fri, Feb 3, 2017 at 12:23 PM, Peter <j...@zeus.net.au> wrote: > > No serialization or Remote method invocation framework currently supports > OSGi very well, one that works well and can provide security might gain a > lot of new interest from that user base.

Re: OSGi

tp://blog.osgi.org/2008/08/classy-solutions-to-tricky-proxies.html?m=1 >> >> Regards, >> >> Peter. >> >> Sent from my Samsung device. >> >> Include original message >> Original message >> From: Peter <j...@zeus.net.au> >&g

Re: OSGi

eter <j...@zeus.net.au> > Sent: 03/02/2017 02:23:25 pm > To: dev@river.apache.org <d...@riverapache.org> > Subject: Re: OSGi > > Thanks Gregg, > > I realise that Jini may have been a lot more successful had your experiences > with desktop applications been given

Re: OSGi

message From: Peter <j...@zeus.net.au> Sent: 03/02/2017 02:23:25 pm To: dev@river.apache.org <d...@riverapache.org> Subject: Re: OSGi Thanks Gregg, I realise that Jini may have been a lot more successful had your experiences  with desktop applications been given greater consideration.

Re: OSGi

of the Java runtime will still work in non-jini packages. Gregg > On Feb 1, 2017, at 7:44 PM, Peter <j...@zeus.net.au> wrote: > > Thanks Gregg, > > I think it's necessary to continue supporting preferred class loading for > those who don't use osgi or maven. Rio a

Re: OSGi

Thanks Gregg, I think it's necessary to continue supporting preferred class loading for those who don't use osgi or maven.  Rio already has a maven class resolver RMIClassLoaderSPI implementation.  But we also need to ensure we can still solve the same problems that preferred class loading

Re: OSGi

on your Entry classes that need to be preferred? > > Thanks, > > Peter. > > Sent from my Samsung device. > > Include original message > Original message > From: Gregg Wonderly <ge...@cox.net> > Sent: 31/01/2017 12:56:56 am > To: dev@river.apa

Re: OSGi

sion v = new Version(object.toString()); return v; } } // must be java interface or java class return new Version(0,0,0); } http://blog.osgi.org/2015/12/using-requirements-and-capabilities.html https://www.infoq.com/news/2011/03/osgi-43 http://bnd.bndtools.org/chapters/220-contracts.html On W

Re: OSGi

sion v = new Version(object.toString()); return v; } } // must be java interface or java class return new Version(0,0,0); } http://blog.osgi.org/2015/12/using-requirements-and-capabilities.html https://www.infoq.com/news/2011/03/osgi-43 http://bnd.bndtools.org/chapters/220-contracts.html On W

Re: OSGi

Gregg, Have you got some more detail on your Entry classes that need to be preferred? Thanks, Peter. Sent from my Samsung device.     Include original message Original message From: Gregg Wonderly <ge...@cox.net> Sent: 31/01/2017 12:56:56 am To: dev@river.apache.org Subject: Re

Re: OSGi

he.org Subject: Re: OSGi Peter, Please note that Package admin service has been replaced by the Bundle wiring api. So we may need to use this new api. Thanks & Regards, Bharath On 01-Feb-2017 8:50 AM, "Peter" <j...@zeus.net.au> wrote: Thanks Nic, So it follows that the ca

Re: OSGi

package ranges it's proxy imports in an Entry (we need a new Entry in the Jini platform to support OSGi). The client must be using the latest currently loaded service api packages within the proxy's import ranges, as they will be selected by the framework for the proxy. There is a special case w

Re: OSGi

encapsulating object's Bundle  cannot.  To avoid creating a new incompatible bundle all preceeding bundles in the stack for that serialized object graph should be tried before installing a bundle from a codebase annotation. Clearly we need to know if we're deserializing into an OSGi framework and modify

Re: OSGi

currently loaded in the client jvm.  Hence the service needs to publish the api package ranges it's proxy imports in an Entry (we need a new Entry in the Jini platform to support OSGi). The client must be using the latest currently loaded service api packages within the proxy's import ranges

Re: OSGi

t; environment differently (or all parties in the distributed system > must share the same versions of the code - which makes the whole point of > OSGI moot) > > The only way I can see around this is not to treat jar files downloaded > dynamically as bundles > but rather create

Re: OSGi

environment differently (or all parties in the distributed system must share the same versions of the code - which makes the whole point of OSGI moot) The only way I can see around this is not to treat jar files downloaded dynamically as bundles but rather create fake bundles from them

Re: OSGi

As I think you know, the whole purpose of OSGi is to NOT tie the resolution to Bundles, but to explicitly Exported (with versions) packages. If people screw up and don't declare the Import/Export package meta data correctly, then ordinary OSGi may fail just as spectacularly. The difference being

Re: OSGi

original message Original message From: Michał Kłeczek <michal.klec...@xpro.biz> Sent: 01/02/2017 05:29:09 am To: dev@river.apache.org Subject: Re: OSGi Unfortunately it is not going to work in the general case as I've shown in another message. The issue is that since you do no

Re: OSGi

to be resolved from the same bundle for both. Michal On Tue, 31 Jan 2017 at 06:38, Bharath Kumar <bharathkuma...@gmail.com> wrote: > With help of some information from service providers, we can implement > this use case in osgi environment easily. > > Suppose if we split these c

Re: OSGi

t the full container is necessary and the client does not have it - well... On the other hand. How do you manage upgrades of the OSGI container due to - let's say - a security issue in current implementation? Thanks, Michal Niclas Hedhman wrote: It doesn't sound very intelligent to download an OSGi

Re: OSGi

of the OSGI container due to - let's say - a security issue in current implementation? Thanks, Michal Niclas Hedhman wrote: It doesn't sound very intelligent to download an OSGi Container to a client. It surely is something wrong with that... Proxy should depend on the deployed services, locally

Re: OSGi

t codebases instead of only Strings) 3. (Optionally) - provide a default class conveyance mechanism that: a) allows resolving classes in non-hierarchical way (similar to ClassWorlds or JBossModules or... OSGI) b) supports coexisting of other "class conveyance mechanisms" in the same J

Re: OSGi

With help of some information from service providers, we can implement this use case in osgi environment easily. Suppose if we split these classes as separate bundles, we will have 2 sets of bundles. 1. ImplementationDetail.api - contains ImplementationDetail service api class and its

Re: OSGi

network via this proxy service. Of course other mechanisms for class conveyance are possible and in fact already exist. Maven and even OSGi provide class, version oriented conveyance from a distribution point, into a particular JVM instance. Once the class definition exists inside of one of those

Re: OSGi

I believe that it can be implemented in OSGi environment and we annotate the proxy with 2 codebase annotations. On Jan 30, 2017 9:06 PM, Michał Kłeczek (XPro Sp. z o. o.) < michal.klec...@xpro.biz> wrote: > Let me once again provide a simple example: > > inte

Re: OSGi

Let me once again provide a simple example: interface ForClient { } interface ImplementationDetail { } class ServiceProxy implements ForClient { private ImplementationDetail implementationDetail; } class ServiceBackend { //not implementing any remote interface for simplicity public

Re: OSGi

to stress - I am actually quite negative about OSGI being the right environment for this. Thanks, Michal Gregg Wonderly wrote: Maybe you can help me out here by explaining how it is that execution context and class visibility are both handled by OSGi bundles. For example, one of my client ap

Re: OSGi

Maybe you can help me out here by explaining how it is that execution context and class visibility are both handled by OSGi bundles. For example, one of my client applications is a desktop environment. It does service look up for all services registrations providing a “serviceUI

Re: OSGi

Some thoughts on api design in OSGi en. http://blog.bjhargrave.com/2013/10/api-design-practices-that-work-well.html?m=1 On 30-Jan-2017 3:34 PM, Michał Kłeczek (XPro Sp. z o. o.) < michal.klec...@xpro.biz> wrote: > What I think Jini designers did not realize is that class lo

Re: OSGi

he matter of glueing the pieces together. Thanks, Michal Gregg Wonderly wrote: I am not an OSGi user. I am not trying to be an OSGi opponent. What I am trying to say is that I consider all the commentary in those articles about TCCL not working to be just inexperience and argument to try and

Re: OSGi

working on this is also that OSGI is not the right choice either :) What I also understood is that even having a "module" concept in Java is not enough :) Any solution needs to make a distinction between: - a static notion of a module (in OSGI it is a bundle, in current Jini - a module r

Re: OSGi

A, you need (as if it was a separate service), to resolve it using the proper code sources. I understand how to do this with TCCL, and I also understand how it might be done with some other class loading mechanism. The question is, for OSGi bundles, how does a bundle loader manager make th

Re: OSGi

f.child2Api" > >>> exporting bundles installed. > >>> > >>> So: > >>> 1. The information about BImpl is no longer on the stack and not > >>> available when loading Child2 > >>> 2. Even if it was available (because for exa

Re: OSGi

ks, Michal Peter wrote: Ah yes, that's easy, assuming all classes are Serializable :) Firstly we register a BundleListener with our OSGi framework and keep track of installed Bundles. So Root, is the object graph root, Classes Child1 and Child2 are visible to Root. The first thing we do is pus

Re: OSGi

rialize the BundleWiring information and recreate it when deserializing. You need the snapshot of runtime state - declarative dependency information is not enough. Thanks, Michal Peter wrote: Ah yes, that's easy, assuming all classes are Serializable :) Firstly we register a BundleListener with our

Re: OSGi

dependency information is not enough. Thanks, Michal Peter wrote: Ah yes, that's easy, assuming all classes are Serializable :) Firstly we register a BundleListener with our OSGi framework and keep track of installed Bundles. So Root, is the object graph root, Classes Child1 and Child2 are visib

Re: OSGi

uld happen? Gregg On Jan 27, 2017, at 11:39 AM, Bharath Kumar<bharathkuma...@gmail.com> wrote: Yes Peter. Usage of thread context class loader is discouraged in OSGi environment. http://njbartlett.name/2012/10/23/dreaded-thread-context-classloader.html Some of the problems are hard

Re: OSGi

Ah yes, that's easy, assuming all classes are Serializable :) Firstly we register a BundleListener with our OSGi framework and keep track of installed Bundles. So Root, is the object graph root, Classes Child1 and Child2 are visible to Root. The first thing we do is push the ClassLoader

Re: OSGi

to resolve to classes that thread’s execution already can resolve. What other use of a context class loader would happen? Gregg On Jan 27, 2017, at 11:39 AM, Bharath Kumar<bharathkuma...@gmail.com> wrote: Yes Peter. Usage of thread context class loader is discouraged in OSGi envir

Re: OSGi

before it has been resolved. The information required to deserialized an OSGi graph is in the OIS implementation. The OIS implementation is not visible to the extending MarshalInputStream implementation. MarshalInputStream contains a ClassLoader field, defaultLoader. So the codebase

Re: OSGi

. The information required to deserialized an OSGi graph is in the OIS implementation. The OIS implementation is not visible to the extending MarshalInputStream implementation. MarshalInputStream contains a ClassLoader field, defaultLoader. So the codebase annotation is critical for the identity

Re: OSGi

an object at the head of the branch. * The OIS knows the types of fields in the local class as well as the types of fields in the deserialized class before it has been resolved. The information required to deserialized an OSGi graph is in the OIS implementation. The OIS implementation

Re: OSGi

class as well as the types of fields in the deserialized class before it has been resolved. The information required to deserialized an OSGi graph is in the OIS implementation. The OIS implementation is not visible to the extending MarshalInputStream implementation. MarshalInputStream

Re: OSGi

gmail.com> Sent: 28/01/2017 04:39:57 am To: dev@river.apache.org Subject: Re: OSGi Yes Peter. Usage of thread context class loader is discouraged in OSGi environment. http://njbartlett.name/2012/10/23/dreaded-thread-context-classloader.html Some of the problems are hard to solve in OSGi

Re: OSGi

thkuma...@gmail.com> wrote: > > Yes Peter. Usage of thread context class loader is discouraged in OSGi > environment. > > http://njbartlett.name/2012/10/23/dreaded-thread-context-classloader.html > > Some of the problems are hard to solve in OSGi environment. For example,

Re: OSGi

The ultimate issue is visibility of classes. From most perspectives, there is an execution graph that implies moments when new classes are touched/needed. Where OSGi introduces bundles, it erases the ability to depend on that graph to “expose” the correct version of classes to the correct

Re: OSGi

Thanks Gregg, Thoughts inline below. Cheers, Peter. On 27/01/2017 12:35 AM, Gregg Wonderly wrote: Is there any thought here about how a single client might use both an OSGi deployed service and a conventionally deployed service? Not yet, I'm currently considering how to support OSGi

Re: OSGi

uma...@gmail.com> wrote: > OSGI has already recommended about versioning the package (semantic > versioning). > https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf > > OSGI follows a specific version format (major.minor.micro.qualifier). > > As th

Re: OSGi

OSGI has already recommended about versioning the package (semantic versioning). https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf OSGI follows a specific version format (major.minor.micro.qualifier). As the paper suggested, consumer will not be impacted if there are no changes

Re: OSGi

e 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: >>>&

Re: OSGi

tity 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

Re: OSGi

ot; :) 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 remo

Re: OSGi

Unfortunatelly this is not that easy - the assumption that "the same bundle is going to be resolved in the same way in another OSGI container" is false. Not only the containers must share common provisioning infrastructure (single view of the names) but - most importantly - the

Re: OSGi

trings. 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 i

Re: OSGi

the proxy can be deserialized the RMIClassLoader must first determine whether the proxy's bundle (exact version) exists, if not it needs to request OSGi to provision & load that bundle. When the proxy bundle is loaded, it imports the same service api packages visible to the client. But ho

Re: OSGi

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

Re: OSGi

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

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

Re: OSGi

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

Re: OSGi

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

Re: OSGi

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

Re: OSGi

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

Re: OSGi

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

Re: OSGi

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

Re: OSGi

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

Re: OSGi

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 O

Re: OSGi

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 t

Re: OSGi

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,

Re: OSGi

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

Re: OSGi

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

Re: OSGi

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

Re: OSGi

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

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

<    1   2   3   >