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

Nope - not at all. I am only trying to convince you that there is no reason to involve ServiceRegistrar or SDM for code downloading. HOW the class resolution is done - is another story. I actually tend to think in a similar way to what Niclas said: Do not use OSGi to load proxy class - create a

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.)" Sent: 13/02/2017 11:34:45

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 resoluti

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

1. The connection can be done using normal (secure) Jeri. We do not have to verify the installer object since its classes were loaded locally and (by definition) are trusted. 2. The attacker cannot instantiate any non-local class. That is the whole point. Since the "installer" classes must be

Re: OSGi - deserialization remote invocation strategy

ude original message Original message From: "Michał Kłeczek (XPro Sp. z o. o.)" 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 object that will download some m

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 wiring

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 d

Re: Changing TCCL during deserialization

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ł Kłeczek (XPro

Re: Changing TCCL during deserialization

ass 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.) wrote: What I was specifically asking for is whether this is needed during deserialization or after deserialization. In other words - if I

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.) wrote: Hi, During my work on object based annotations I realized it would be more efficient not to look for TCCL upon every call

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 pa

Re: AbstractILFactory bug?

not 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.)" Sent: 06/02/2017 05:06:32 pm To: dev@river.apache.org S

Re: OSGi

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

ifficult undertaking, but that's probably 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.)

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 loade

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.)" 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/writeObject methods means that you are

Re: Serialization issues

e looking 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.)&q

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 n

Re: Serialization Formats, Previously: OSGi

ather than technological. 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

Re: Serialization issues

Sun, Feb 5, 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 Ni

Re: OSGi

o download via HTTP. Gregg On Feb 4, 2017, at 2:02 AM, Michał Kłeczek (XPro Sp. z o. o.) wrote: 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: Serialization issues

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

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 als

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

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 arguments

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 ob

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 Ni

Re: object based annotations

of unnecessary dns calls. 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.)" Sent: 02/02/2017 06:29:55 am To: dev@river.a

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 encodi

Re: OSGi

Rant aside... This is what I am saying all along... Bundles are not good candidates for codebase annotations. For exactly the reason you describe: bundles represent a template that may produce different wirings. But to recreate an object graph you need the _wiring_ - not the template. And th

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 decide

Re: OSGi

rvices, locally 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. Mani

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 void

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

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 implementatio

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 worki

Re: OSGi

nsure that we allow them to communicate accross compatible versions. Hope this helps clarify 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 ass

Re: OSGi

d1 can be created, and bundle C1's ClassLoader 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/des

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 c

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

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 all

Re: OSGi

t 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: dev@river.apache.org Subject: Re: OSGi I haven't been aware of ObjectSpace Voyager. I just briefly looked at it and it seems l

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 ( :-) ) on

Re: OSGi

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 Subj

Re: OSGi

rences. 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 obje

Re: OSGi

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<mailto:michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz>> wrote: The us

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 RemoteEve

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 OSGI

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 ca

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

t class) 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 a

Re: Maven Build

common api. No unintended code versioning conflicts. >>>> >>>> This choice would not prevent or exclude other methods of >> communication, >>> the service, even if isolated within it's own process will still >>> communicate r

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 pro

Re: River's Future

This is interesting but the link is broken. Michal Peter October 11, 2016 at 10:02 AM I'd like to donate atomic input validation for Java serialization to River. At least one security researcher has provided some initial positive feedback. See the comments at th

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 ab

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