Re: [DISCUSS] Moving Apache River to the Attic

Hi Peter, > On 16 Feb 2022, at 10:01, Peter Firmstone wrote: > > Inline below. > > On 16/02/2022 5:24 pm, Michał Kłeczek wrote: >> >>> On 16 Feb 2022, at 04:25, Peter Firmstone >>> wrote: >>> >>> From the CodebaseAccessor service. &

Re: [DISCUSS] Moving Apache River to the Attic

> On 16 Feb 2022, at 04:25, Peter Firmstone wrote: > > From the CodebaseAccessor service. > > The CodebaseAccessor proxy (local code) is passed as a parameter along with a > MarshalledInstance of the proxy, by ProxySerializer to ProxyCodebaseSpi. > >

Re: [DISCUSS] Moving Apache River to the Attic

Follow up: > On 15 Feb 2022, at 13:05, Peter Firmstone wrote: > > >> >> - How do you provide the above mentioned JavaSpaceEventPublisher >> - How would you provide a java.sql.DataSource as a service? > > > If you don't have an ObjectEndpoint, then there is no one to authenticate, > you

Re: [DISCUSS] Moving Apache River to the Attic

> On 15 Feb 2022, at 13:05, Peter Firmstone wrote: > > >> How the client knows the code needed to deserialise? > The service provides this information, typically in a services configuration, > How is this configuration provided to the client and when? > by default this is a space separated

Re: [DISCUSS] Moving Apache River to the Attic

Hi Peter, > JGDMS uses a new implementation of a subset of the Java Serialization’s > stream format, with input validation and defenses against malicious data (all > connections are first authenticated when using secure endpoints). Codebase > annotations are no longer appended in

Re: [DISCUSS] Moving Apache River to the Attic

Hi All, Based on the excelent work of (mainly) Peter Firmstone (et al) I am personally working on “River 4.0” right now and was planning to share my work with the community soon(tm). 1. Implementation of my old idea of making codebase annotations objects implementing a specific interface

Re: JEP 411 - end of Apache River?

> maybe the JDK should look into adopting the Android way. > > > >> On Fri, Apr 30, 2021 at 4:38 AM Michał Kłeczek wrote: >> >> >> >>> On 30 Apr 2021, at 04:42, Jeremy R. Easton-Marks < >> j.r.eastonma...@gmail.com> wrote: >>>

Re: JEP 411 - end of Apache River?

> On 30 Apr 2021, at 04:42, Jeremy R. Easton-Marks > wrote: > > I'm not sure how much JEP 411 will impact River. I agree with the overall > direction that it proposes in removing the security manager. IMHO JEP 411 gives unconvincing reasons to ditch SecurityManager: - brittle permission

JEP 411 - end of Apache River?

Hi All, I’ve just learned JEP 411 (https://openjdk.java.net/jeps/411 ) moved to Candidate status. Does this JEP mean end of mobile code and hence Apache River? Thanks, Michal

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

to understand your perspective better. The questions and comments/answers here are not going to be very good if you are just demanding our time, and not spending your time to learn the details what Peter is pointing out about how River works. Gregg On Feb 15, 2017, at 1:00 AM, Michał Kłecze

Re: deserialization remote invocation strategy

. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek<mic...@kleczek.org> Sent: 15/02/2017 08:04:39 pm To: dev@river.apache.org Subject: Re: deserialization remote invocation strategy The code actually does what I've described above, but

Re: deserialization remote invocation strategy

The code actually does what I've described above, but don't take my word for it, check it for youself. :) If you disagree, don't use it. It works the other way around - before I decide to use it - I have to understand how it works. Even more so if we are talking about security. That is why

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

he bootstrap proxy be loaded by the codebase ClassLoader? Regards, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek<mic...@kleczek.org> Sent: 15/02/2017 06:20:37 am To: dev@river.apache.org Subject: Re: OSGi NP

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

the code of the service proxy is already trusted (we have established trust before downloading it) - we can simply place the constraints on the service proxy that instructs it to only download code meeting certain criteria. Am I correct in my thinking? Thanks, Michal Michał Kłeczek wrote

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Let me dig some deeper. Comments inline. Peter wrote: Yes the dynamic proxy's are 100% local code. Remember dynamic proxy's don't have codebase s. :) Of course they do - look at PreferredClassProvider - the dynamic proxy class is defined by the codebase loader! Being a dynamic proxy does

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

It seems like I am missing the high level view on the architecture of your software. Would it be possible for you to write one? Peter wrote: There's a new constraint AtomicInputValidation that jeri uses to prevent standard serialization being used. Reggie has been granted DownloadPermission

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Comments inline. Peter wrote: Some of your assumptions around forbidding code downloading are incorrect, which means the other assumptions that rely upon it are also wrong. Which assumptions? I know about DownloadPermissions. And while using RequireDlPermProvider closes the security

Deserialization vulnerabilities

Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek<mic...@kleczek.org> Sent: 14/02/2017 01:55:56 am To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy It i

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Wouldn't it be easier if you simply forbid code downloading during unmarshalling as in SmartProxyWrapper I've shown in another message? Then u use the unmarshalled bootstrap object to securely download the real proxy using existing Jeri implementation. Then you do not need any advanced

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

wrapper authenticate the service before codebase and smart proxy download? Sent from my Samsung device. Include original message Original message From: Michał Kłeczek<mic...@kleczek.org> Sent: 14/02/2017 01:21:46 am To: dev@river.apache.org Subject: Re: OSGi NP Complete Was

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Include original message Original message ---- From: Michał Kłeczek<mic...@kleczek.org> Sent: 14/02/2017 01:27:09 am To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy See below. Peter wrote: Using one of the secure dis

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

much more to support OSGi. Regards, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek<michal@kleczekorg> Sent: 14/02/2017 01:05:54 am To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

See below. Peter wrote: Using one of the secure discovery providers with authentication and input validation. Download and deserialization permissions are granted dynamically just after authentication, but before download. But now you just moved trust decisions to SafeServiceRegistrar

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

validation. Download and deserialization permissions are granted dynamically just after authentication, but before download. Regards, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek<mic...@kleczek.org> Sent: 14/02/2017 01

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

The service has the power to constrain its proxy bundle manifest if it wishes. Regards, Peter. Sent from my Samsung device Include original message Original message ---- From: Michał Kłeczek<mic...@kleczek.org> Sent: 14/02/2017 12:24:58 am To: dev@river.apache.o

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

class with a readResolve method? Sorry. Regards, Peter. Sent from my Samsung device. Include original message Original message From: Michał Kłeczek<mic...@kleczek.org> Sent: 14/02/2017 12:14:41 am To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deseriali

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

From: Michał Kłeczek<mic...@kleczek.org> Sent: 14/02/2017 12:24:58 am To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy Peter wrote: There a multiple remote services, if one client cant obtain a service because there i

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Peter wrote: There a multiple remote services, if one client cant obtain a service because there is also a later version installed then you need a service that doesn't import the later version. You can still supply another service to cater. This does not scale because you would have to have

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Peter wrote: In jgdms I've enabled support for https unicast lookup in LookupLocator this establishes a connection to a Registrar only, not any service. This functionality doesn't exist in River. How do you propose establishing a connection using one of these endpoints? I am not sure I

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

mplete Was: OSGi - deserialization remote invocation strategy Sorry, I'm trying to find out the meaning of the current subject line. I'm not sure when it changed to "OSGi MP Complete". On 2/12/2017 10:50 PM, Michał Kłeczek wrote: Sorry, NP Completness of what? I have been the fir

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

KerberosEnpoint? HttpsEndpoint? Thanks, Michal Peter wrote: How do you establish the secure jeri connection? Regards, Peter. Sent from my Samsung device. Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.klec...@xpro.biz

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Comments inline. Peter wrote: N.B Can't see any chicken egg problem. If service doesn't resolve to same service api as client, then it isn't compatible. The client isn't interested in incompatible services, only those that are compatible This is just an artifact of the dependency

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

choosing a different class to deserialize? Regards, Peter. Sent from my Samsung device Include original message Original message From: Michał Kłeczek<mic...@kleczek.org> Sent: 13/02/2017 10:07:28 pm To: dev@river.apache.org Subject: Re: OSGi NP Complete Was: OSGi - deseria

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

On 13/02/2017 6:11 PM, Michał Kłeczek wrote: We are talking about the same thing. We are turning circles, Peter - all of this has been already discussed. 1. Yes - you need to resolve bundles in advance (in OSGi it is not possible to do otherwise anyway) Agree. 2. You cannot decide upon the bun

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

ys. Cheers, Peter. On 13/02/2017 4:50 PM, Michał Kłeczek wrote: Sorry, NP Completness of what? I have been the first to mention NP hardness of constraint satisfaction problem but I am not sure if this is what you are asking about. Thanks, Michal Patricia Shanahan wrote: Are you literally clai

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Sorry, NP Completness of what? I have been the first to mention NP hardness of constraint satisfaction problem but I am not sure if this is what you are asking about. Thanks, Michal Patricia Shanahan wrote: Are you literally claiming NP Completeness, or just using that as an analogy for

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

I am sorry but I think that to solve various issues we need to make sure fundamentals are right: 1. There is NO such a thing as "reflective non-smart" proxy - EVERY proxy is "smart" (even if it is "reflective") - there is an InvocationHandler down there, isn't there? 2. Solving this on

Re: OSGi - deserialization remote invocation strategy

int and invocation handler and marshal streams) . > > Cheers, > > Peter. > Sent from my Samsung device. > > Include original message > Original message > From: Michał Kłeczek <mic...@kleczek.org> > Sent: 08/02/2017 06:51:55 am > To: dev@riv

Re: OSGi - deserialization remote invocation strategy

. Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.klec...@xpro.biz> Sent: 08/02/2017 05:51:07 am To: dev@river.apache.org Subject: Re: OSGi - deserialization remote invocation strategy So I must have misunderstood the part about sma

Re: OSGi - deserialization remote invocation strategy

ude original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.klec...@xpro.biz> Sent: 08/02/2017 12:28:50 am To: dev@river.apache.org Subject: Re: OSGi - deserialization remote invocation strategy Are you proposing to provide a bootstrap

Re: OSGi - deserialization remote invocation strategy

Comments inline Niclas Hedhman wrote: 4. For Server(osgi)+Client(osgi), number of options goes up. In this space, Paremus has a lot of experience, and perhaps willing to share a bit, without compromising the secret sauce? Either way, Michal's talk about "wiring" becomes important and that

Re: Changing TCCL during deserialization

This is fine for me. I am asking not about one interaction where multiple instances of MarshalledInputStreams are used (each with its own TCCL) I am asking about the situation described in another email - that during a deserialization using a single instance of the stream the TCCL is changed.

Re: OSGi - deserialization remote invocation strategy

Are you proposing to provide a bootstrap object that will download some meta information prior to class resolution? How does it differ from simply changing annotations to be those "bootstrap objects" instead of Strings? Thanks, Michal Peter wrote: Proposed JERI OSGi class loading strategy

Re: Changing TCCL during deserialization

ng thread can resolve, and Item in this specific case in particular, and you would thus potentially see Item come from another class loader than you intended (the services class loader with “null” as the parent), and this will result in either a CNFE or CCE. Gregg On Feb 6, 2017, at 11:28 AM, Michał

Re: Changing TCCL during deserialization

rvices class loader with “null” as the parent), and this will result in either a CNFE or CCE. Gregg On Feb 6, 2017, at 11:28 AM, Michał Kłeczek (XPro Sp. z o. o.)<michal.klec...@xpro.biz> wrote: What I was specifically asking for is whether this is needed during deserializat

Re: Changing TCCL during deserialization

own class loader so that the classes it downloads reflect against the existing class definitions. Gregg On Feb 6, 2017, at 12:03 AM, Michał Kłeczek (XPro Sp. z o. o.)<michal.klec...@xpro.biz> wrote: Hi, During my work on object based annotations I realized it would be more efficient not to

Re: AbstractILFactory bug?

I'm talking about this: Util.checkPackageAccess(interfaces[i].getClass()); //NOTE the getClass() here!!! It should be: Util.checkPackageAccess(interfaces[i]); Michal Michał Kłeczek (XPro Sp. z o. o.) wrote: I understand the check is needed. It is that we are not checking the right package

Re: AbstractILFactory bug?

t checking it would allow an attacker to bypass the check using AbstractILFactory. Cheers, Peter. Sent from my Samsung device. Include original message Original message ---- From: "Michał Kłeczek (XPro Sp. z o. o.)"<michalklec...@xpro.biz> Sent: 06/02/2017 05:06:32 p

Re: OSGi

. - this is not needed anymore. Thanks, Michal Michał Kłeczek (XPro Sp. z o. o.) wrote: Well - times changed since original Jini has been developed. There is a whole lot of amazing libraries out there - so the undertaking is much easier than doing it without them. I am specifically talking about Google

AbstractILFactory bug?

I have just found this piece of code in AbstractILFactory: Class[] interfaces = getProxyInterfaces(impl); ... for (int i = 0; i < interfaces.length; i++) { Util.checkPackageAccess(interfaces[i].getClass()); } So we check "java.lang" package access. A bug? Thanks, Michal

Re: OSGi

an attraction right? Maybe River could provide some interfaces for extensibility where you could plug in? Regards, Peter. Sent from my Samsung device. Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.klec...@xpro.biz> Sent: 06/02/

Changing TCCL during deserialization

Hi, During my work on object based annotations I realized it would be more efficient not to look for TCCL upon every call to "load class" (when default loader does not match the annotation). It might be more effective to look it up upon stream creation and using it subsequently for class

Re: OSGi

Once you realize you need some codebase metadata different than mere list of URLs the next conclusion is that annotations should be something different than... a String :) The next thing to ask is: "what about mixed OSGI and non-OSGI environments" Then you start to realize you need to abstract

Re: Serialization issues

Original message From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.klec...@xpro.biz> Sent: 05/02/2017 04:04:03 am To: dev@river.apache.org Subject: Re: Serialization issues You do not have to do any IO in readObject/writeObject. The fact that you have readObject/wri

Re: Serialization issues

into this, I came across https://www.usenix.org/legacy/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/index.html, which might be to your interest. Not totally relevant, but still an interesting read. Cheers On Sun, Feb 5, 2017 at 2:04 AM, "Michał Kłeczek (XPro Sp. z o. o.)"<

Re: Serialization issues

. Because to me I can't figure out any use-case where that is a problem... On Sun, Feb 5, 2017 at 1:14 AM, "Michał Kłeczek (XPro Sp. z o. o.)"< michal.klec...@xpro.biz> wrote: Don't know about other serialization uses but my issue with it is that it precludes using it in non-blockin

Re: Serialization Formats, Previously: OSGi

I don't have the answers, other than; Without Constraints Technology Fails. And the better the constraints are defined, the better likelihood that it can succeed. On Sat, Feb 4, 2017 at 8:59 PM, "Michał Kłeczek (XPro Sp. z o. o.)"< michal.klec...@xpro.biz> wrote: Comments b

Re: Serialization issues

, 2017 at 12:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)"< michal.klec...@xpro.biz> wrote: It is not possible to do non-blocking as in "non blocking IO" - meaning - threads do not block on IO operations. Just google "C10K problem" Thanks, Michal Niclas Hedhm

Re: OSGi

o download via HTTP. Gregg On Feb 4, 2017, at 2:02 AM, Michał Kłeczek (XPro Sp. z o. o.)<michal.klec...@xpro.biz> wrote: My annotated streams replace codebase resolution with object based one (ie - not using RMIClassLoader). Michal Gregg Wonderly wrote: Why specific things

Re: Serialization issues

at would mean in CPU-only circumstance). Feel free to elaborate... I am curious. On Sat, Feb 4, 2017 at 8:38 PM, "Michał Kłeczek (XPro Sp. z o. o.)"< michal.klec...@xpro.biz> wrote: Unfortunately due to "writeObject" and "readObject" methods that have to be handled (to

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 mak

Serialization issues

Unfortunately due to "writeObject" and "readObject" methods that have to be handled (to comply with the spec) - it is not possible to serialize/deserialize in a non-blocking fashion. So yes... - it is serialization per se. Thanks, Michal Niclas Hedhman wrote: Oh, well that is not

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

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

I know that. And while it is better than Java RMI for several reasons (extensibility being one of them) - it is still not perfect: 1) It is inherently blocking 2) Does not support data streaming (in general you need a separate comm channel for this) 3) invocation layer depends on particular

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: object based annotations

. But it sounds like you may have found an alternative option. Regards, Peter. Sent from my Samsung device. Include original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.klec...@xpro.biz> Sent: 02/02/2017 06:29:55 am To: dev@river.apache

Re: object based annotations

I have actually given up on the idea of object annotations encoded as Strings (in whatever form). Simply speaking it does not make any sense really: - it would complicate the solution because of additional encoding and decoding logic - it would influence performance because of additional

Re: OSGi

for the rant... Back to OSGi; even if you really need to tie a class to a particular bundle, you can do that with attributes and the 'mandatory' directive. Cheers Niclas On Wed, Feb 1, 2017 at 3:29 AM, Michał Kłeczek<michal.klec...@xpro.biz> wrote: Unfortunately it is

Re: OSGi

t service instances are resolved and some kind of class > > loading context is attached to that service. > > > > The reason I am talking specifically about directed graphs of class > > loading is because I am first focused on the fact that there is a lot > less > > flexi

Re: OSGi

I meant "of course it is NOT too intelligent". Freudian mistake :D Michał Kłeczek (XPro Sp. z o. o.) wrote: Of course it is too intelligent. What I am saying is that it is at service provider's discretion to decide how to load its own proxy classes. If a service decides tha

Re: OSGi

some more... What am I missing, other than you are trying to convey an absurdity? On Tue, Jan 31, 2017 at 4:10 PM, "Michał Kłeczek (XPro Sp. z o. o.)"< michal.klec...@xpro.biz> wrote: My point throughout the whole thread is that to support these scenarios: 1. Manipulating cla

Re: OSGi

My point throughout the whole thread is that to support these scenarios: 1. Manipulating class streams (like in Voyager) is not necessary (quite franky - I think it is a bad idea actually since it assumes a single namespace for classes what precludes class evolution) 2. Dictating a particular

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

ing which is controlled outside of the service discovery moment. On Jan 30, 2017, at 4:04 AM, Michał Kłeczek (XPro Sp. z o. o.)<michal.klec...@xpro.biz> wrote: What I think Jini designers did not realize is that class loading can be treated exactly as any other capability provide

Re: OSGi

What I think Jini designers did not realize is that class loading can be treated exactly as any other capability provided by a (possibly remote) service. Once you realize that - it is possible to provide a kind of a "universal container infrastructure" where different class loading

Re: OSGi

I absolutely agree with the requirements you state. The problem with Jini (and hence River) usage of TCCL is that it assumes a parent-child relationship between class loaders - which in turn causes the issues with transferring object graphs I've described earlier. What I understood when

Re: OSGi

her, then > if we don't have full control over both JVM's then we may introduce > incompatibility at the root object, thus causing a ClassCastException > when the caller in the deserializing jvm tries to assign it to Root. > > We can't design a system for all scenarios, all systems have

Re: OSGi

it a little better. Cheers & thanks, Peter. On 28/01/2017 10:11 PM, "Michał Kłeczek (XPro Sp. z o. o.)" wrote: Ahh... You've missed the important part :) - child2. You cannot assume BImpl class loaded in context of C1 is assignable to child2 - it depends on what other unrelate

Re: OSGi

lassLoader is popped off the stack. The same process is repeated for Child2. Cheers, Peter. On 28/01/2017 7:41 PM, "Michał Kłeczek (XPro Sp. z o. o.)" wrote: I fail to see how it could possibly work. Could you walk step-by-step serialize/deserialize with the following object graph: B

Re: OSGi

I would say that using TCCL as is a poor man's approach to class resolution. Once you have codebase identity done right - it is not needed anymore. Thanks, Michal Gregg Wonderly wrote: The commentary in the first document indicates that there is no rhyme or reason to the use of the context

Re: OSGi

In general I think implementing class resolution logic in stream implementation is bad. It has to be decoupled. Thanks, Michal Peter wrote: So here's how we can put it together: Our OIS contains a stack we can use to track ClassLoader's at each branch in our serialized object graph. 1.

Re: OSGi

I fail to see how it could possibly work. Could you walk step-by-step serialize/deserialize with the following object graph: Bundle API: interface Api {} Bundle BR: class Root { Child1 child1; Child2 child2; Api getApi() { return isEven(getRandom()) ? child1.impl : child2.impl; }

Re: OSGi

k the code server for a new CodeBaseModule - which in turn could return a newer patched version of it. Cheers, Michal Michał Kłeczek (XPro Sp. z o. o.) wrote: So for a client and a service to be able to communicate they must agree on a common set of interchangeable CodeRepositories that would

Re: OSGi

ng device. Include original message Original message ---- From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.klec...@xpro.biz> Sent: 26/01/2017 08:30:58 am To: dev@river.apache.org Subject: Re: OSGi I haven't been aware of ObjectSpace Voyager. I just briefly looked at it a

Re: OSGi

constitute as single entity - there is a bootstrap well known CodeRepository (Maven central?) - its implementation is based on a well known URL and its implementation code is shipped with the framework. Thanks, Michal Michał Kłeczek (XPro Sp. z o. o.) wrote: Honestly - since I am fixed

Re: OSGi

base 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.)"<michal.klec...@xpro.biz> Sent: 26/01/2017 08:30:58 am

Re: OSGi

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

Re: OSGi

SmartProxy deserialization? Gregg On Jan 23, 2017, at 2:39 PM, Michał Kłeczek (XPro Sp. z o. o.)<michal.klec...@xpro.biz> wrote: Gregg Wonderly wrote: michal.klec...@xpro.biz<mailto:michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz> <mailto:michal.klec...@x

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

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

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: site revamp

Hi, Great job! Could you link the mother of all Jini guides? https://jan.newmarch.name/java/jini/tutorial/Jini.html Thanks, Michal Geoffrey Arnold December 22, 2016 at 8:44 PM Hey Zsolt, really fantastic job. Well done! Zsolt Kúti

Re: Maven Build

ss) identity. That would also allow solving the problem above. Thanks, Michal Niclas Hedhman <mailto:nic...@hedhman.org> November 16, 2016 at 11:53 PM On Wed, Nov 16, 2016 at 8:43 PM, "Michał Kłeczek (XPro Sp. z o. o.)"< michal.klec...@xpro.biz> wrote: 3. My comment about

Re: Maven Build

e >>> two companies, code from each remains isolated and communicates only >> using >>> common api. No unintended code versioning conflicts. >>>> >>>> This choice would not prevent or exclude other methods of >>

Re: Maven Build

al to and independant of remote communication protocols. > > > > OSGi would of course be an alternative option, if one wished to execute > incompatible versions of libraries etc within one process, but different > trust domains will have a shared identity, again this may not

Re: Maven Build

While I also thought about out-of-process based mechanism for execution of dynamically downloaded code, I came to the conclusion that in the context of River/Java in-process mechanism is something that MUST be done right. All other things can (and should) be built on that. I think that the

Re: another interesting link

>> 2. proxy codebase jars contain a list of requested permissions to be granted to the jar signer and url (client need not know in advance). This one is tricky: 1) It is not always possible to specify fine grained permissions statically (for example we want to restrict the connect permission to

Re: another interesting link

I am well aware of StartNow since that is the first Jini "support library" I have used. Indeed - it is really easy to use. But it is only one side of the issue - the API and some support support code that is supposed to be linked statically with the service implementation. What I am talking

Re: another interesting link

In my dreams I always thought of "self configuring" and "adapting" services. So instead of reading a "configuration" a service would simply search for other services and use them. Exporter service being an example. Ideally - the only thing that should be configured would be the "identity" (ie.

  1   2   >