Thanks Gregg, those are very good points.
Cheers,
Peter.
On 2/10/2017 10:35 PM, Gregg Wonderly wrote:
I like the constructor argument mechanism as it becomes thread local detail,
rather than VM level detail. Too many “platform” things in Java have ended up
being “service type platform” lik
I like the constructor argument mechanism as it becomes thread local detail,
rather than VM level detail. Too many “platform” things in Java have ended up
being “service type platform” like, instead of multiple services platform like.
Keeping things thread of execution specific helps us suppo
I'm considering api that may be required for improved OSGi support.
In order for an OSGi environment to deserialize a proxy, it needs to
first install a bundle for the proxy and resolve any dependencies. For
OSGi a ProxyPreparer must first locally marshall (create a
MarshalledInstance) a java
Yes, I've been thinking about it.
My current thoughts; ServiceUI can be accessed through
net.jini.lookup.ServiceAttributesAccessor, so you can unmarshall
ServiceUI objects, without unmarshalling the service itself. However I
haven't given much consideration to locating codebases for ServiceU
Yes that's correct.
Sun chose to use the ClassLoader to represent the service's pincipal,
dynamically granting permission after proxy verification.
So that's what we have available on the call stack to use when
performing authorisation permission checks:
1. Client's Principal. (Principal
Hi Peter,
In reading your missive I'm not sure I understand when you say "Maven will
present a new alternative of maximum sharing, where different service
principals will share the same identity.", or "Maven class resolution".
Are you referring to an approach where a service may declare it's code
Do you have anything planned around ServiceUI? I really use ServiceUI as a
discovery mechanism to find services which export a UI that a user can interact
with. What can happen at registration time, besides Entry specification to
help with codebase where ServiceUI bits are at? Are you just re
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)
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
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 Pr
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 b
Hmm, ASCII keeps getting scrubbed, so here it is:
SERVER JVM
__
| |
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 23/02/2017 03:26:15 pm
To: 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
Mic,
I've taken the liberty to copy paste your questions into the list below
(my apologies if I've missed some), my answers to your questions follow.
I'll apologise in advance, as I don't have time to answer more follow up
questions, perhaps others on the list might be able to assist.
Regar
ll
arguments / assumptions. Sometimes the right questions are more important
than answers.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 15/02/2017 12:58:55 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi
ght questions are more
>> important than answers.
>>
>> Regards,
>>
>> Peter.
>>
>> Sent from my Samsung device.
>> Include original message
>> Original message
>> From: Peter
>> Sent: 15/02/2017 12:58:55 pm
>> To
@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Miscommunication... as usual :D
Anyway - I was really interested why you find the need for the bootstrap
proxy to be necesarilly a dynamic proxy
(since you seemed to find it very important from the
In fact I encourage you to do so as this can
only serve to increase understanding.
Cheers,
Peter
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 15/02/2017 05:00:14 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was:
ginal message
Original message
From: Peter
Sent: 15/02/2017 07:01:06 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Oh I thought it was part of your SmartProxyWrapper?
Who'd have thought you were talking about my wo
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 15/02/2017 05:00:14 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
They are valid questions and you haven't answer
arguments / assumptions. Sometimes the right questions are more important
than answers.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 15/02/2017 12:58:55 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi
all
arguments / assumptions. Sometimes the right questions are more important
than answers.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 15/02/2017 12:58:55 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi -
gards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 15/02/2017 06:20:37 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So I've given it some thought an
e
Original message
From: Michał Kłeczek
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 discovery providers with authentication
and input validation
So I've given it some thought and the only explanation I can come up
with is:
1. To create an instance of the bootstrap proxy you need the codebase
annotation.
2. Codebase annotation is needed because you want the bootstrap proxy's
class to be
defined in the proper codebase ClassLoader
3. Sin
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 no
nvestigate further.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 14/02/2017 09:34:01 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
There's a new constra
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 a
ry.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 07:39:52 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Comments inline.
Peter wrote:
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 vulnerabi
ent: 14/02/2017 03:43:39 pm
To: dev@river.apache.org
Subject: 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
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 discovery
27;t be defined. DownloadPermission is incorrectly
named, it should be called DefineClassPermission.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:45:43 am
To: dev@river.apache.org
Subject: Re: OSGi NP Com
some defensive programming?
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:42:23 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Both ways have
@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
It is as simple as:
interface ServiceProxyDownloader extends Remote, RemoteMethodControl {
Object downloadServiceProxy() throws RemoteException;
}
//this class is local to the client - to make
om my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:45:43 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Peter wrote:
> The codebase is signed and download permission
wrapper authenticate the service before codebase and smart proxy
download?
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:21:46 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization
Include original message
Original message
From: Michał Kłeczek
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 discovery providers with authenti
think we can do much more to support OSGi.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:05:54 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invoc
The codebase is signed and download permission is granted only to the signed
codebase.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:27:09 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:21:46 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So if the CodeDownloadingSmartProxyWrapper implements AtomicSerial then
it is fine?
Cool - lets do that.
Thanks
0, I think we can do much more to support OSGi.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:05:54 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote
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
implem
@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So your SaveUnmarshallingProxy can do input validation fist as well,
can't it?
BTW - how does the client unmarshalls SafeServiceRegistrar proxy in a
secure way?
Thanks,
Michal
Peter wrote:
,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 01:13:04 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So your SaveUnmarshallingProxy can do input
first.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:42:43 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
I fail to understand how you are
at the changes in JGDMS.
SafeServiceRegistrar authenticates and performs input validation first.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:42:43 am
To: dev@river.apache.org
Subject: Re: OSGi NP
--
From: Michał Kłeczek
Sent: 14/02/2017 12:39:40 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
But what if the client has MULTIPLE clients - each with its own exact
API version?
OSGi handles this case just fine with service tracker
ution solve this problem?
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:39:40 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
But wh
local class with a
readResolve method?
Sorry.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:14:41 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invoc
ssage
From: Michał Kłeczek
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 is also a later version inst
Original message
From: Peter
Sent: 14/02/2017 12:33:54 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
You can however for each service api package version, it's all in the smart
proxy bundle manifest.
You are bou
t see why a compelling reason to give that up for a local class with a
readResolve method?
Sorry.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 14/02/2017 12:14:41 am
To: dev@river.apache.org
Subject: Re: OS
gards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
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 multipl
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 o
evice.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 13/02/2017 11:59:34 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Comments inline.
Peter wrote:
N.B Can't
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 unde
nt from my Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 14/02/2017 12:00:02 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
KerberosEnpoint?
Htt
ing against it.
I'm arguing for a background task that preceeds deserialization of the proxy.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Patricia Shanahan
Sent: 13/02/2017 11:27:27 pm
To: dev@river.apache.org
Subject: Re: O
ice.
Include original message
Original message
From: Patricia Shanahan
Sent: 13/02/2017 11:27:27 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Sorry, I'm trying to find out the meaning of the current subject line.
I
pm
To: dev@river.apache.org
Subject: 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 Th
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
o.)"
Sent: 13/02/2017 11:34:45 pm
To: dev@river.apache.org
Subject: 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
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 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete
message
From: Peter
Sent: 13/02/2017 11:15:27 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
So this object that you have with a locally installed class is tasked with
authenticating the remote service, provisioning and reso
choosing a different class to deserialize?
Regards,
Peter.
Sent from my Samsung device
Include original message
Original message
From: Michał Kłeczek
Sent: 13/02/2017 10:07:28 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
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 first to mention NP hardness of constraint satisfaction
problem
but I am not sur
/02/2017 10:07:28 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Comments inline.
Peter wrote:
> Mic,
>
> I'm attempting to get my head around your proposal:
>
> In the case of JERI, the InvocationHandler
Comments inline.
Peter wrote:
Mic,
I'm attempting to get my head around your proposal:
In the case of JERI, the InvocationHandler is part of the smart
proxy's serialized state. A number of smart proxy classes will need
to be unmarshalled before the UnmarshallingInvocationHandler is
deseria
To be fair, my position changed somewhat after Nic's email and some
further research, it may of course develop further with understanding
and experimentation.
Cheers,
Peter.
On 13/02/2017 7:52 PM, Peter wrote:
Mic,
I'm attempting to get my head around your proposal:
In the case of JERI, th
Mic,
I'm attempting to get my head around your proposal:
In the case of JERI, the InvocationHandler is part of the smart proxy's
serialized state. A number of smart proxy classes will need to be
unmarshalled before the UnmarshallingInvocationHandler is deserialized.
The smart proxy contains
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)
2. You cannot decide upon the bundle chosen by the container to load the
proxy class
Also see the OSGi Enterprise specification, v6, Chapter 136, page 691,
there's some discussion about the NP-complete nature of dependency
resolution there as well.
https://www.osgi.org/developer/downloads/release-6/release-6-download/
On 13/02/2017 5:19 PM, Peter wrote:
OSGi Dependency resolu
OSGi Dependency resolution is.
http://underlap.blogspot.com.au/2010/02/osgi-resolution-is-np-complete-so-what.html
Which means if we want to support an OSGi environment properly, we may
need some time to resolve the dependencies for a smart proxy, before
deserializing the proxy, rather than do
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 reall
Are you literally claiming NP Completeness, or just using that as an
analogy for really, really difficult?
On 2/11/2017 1:23 PM, Michał Kłeczek wrote:
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
n, it requires a
codebase.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 12/02/2017 08:42:23 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Thanks Michal,
Thanks Michal,
See inline below.
On 12/02/2017 7:23 AM, Michał Kłeczek wrote:
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") - t
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 service
Thanks Nic,
It looks like OSGi is generating a lot of interest. I'm spending a lot
of time respoding to discussions, which is important, but I'd also like
to get the the existing test suite working with the new JGDMS OGSi
Bundles, so will have to excuse myself as I'm still in the learning
u
> On Feb 7, 2017, at 8:56 AM, Michał Kłeczek (XPro Sp. z o. o.)
> wrote:
>
> 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
Maybe there are some misunderstanding somewhere... see below;
On Wed, Feb 8, 2017 at 3:35 AM, Peter wrote:
> I'm currently only considering OSGi server -> OSGi client. Mick's
investigating all four options.
Ok, makes it a lot easier for me to follow.
> Not expecting the client calling bundle t
Correct in the second instance.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 08/02/2017 09:24:21 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
So in this case there is no
vocation handler and marshal streams) .
>
> Cheers,
>
> Peter.
> Sent from my Samsung device.
>
> Include original message
> Original message
> From: Michał Kłeczek
> Sent: 08/02/2017 06:51:55 am
> To: dev@river.apache.org
> Subject: Re: OSGi
In other words would work where MarshalInputStream is used.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 08/02/2017 06:51:55 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
I think
h its own
jeri endpoint and invocation handler and marshal streams) .
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek
Sent: 08/02/2017 06:51:55 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocat
n made extensible to allow other
> serialization formats to be supported by the api.
>
> But we're diverging...
>
> Cheers,
>
> Peter.
>
> Sent from my Samsung device.
>
> Include original message
> Original message
> From: Michał Kłeczek
&
om: Michał Kłeczek
Sent: 08/02/2017 06:07:19 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
Hmm.. I see.
So your solution explicitly only handles cases of looking up a service
in the ServiceRegistrar.
How about smart RemoteEventListeners? Th
Clarification inline.
Sent from my Samsung device.
Include original message
Original message
From: Peter
Sent: 08/02/2017 05:35:57 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
Hi Nic,
I'm currently only considering OSGi s
om my Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
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 smart proxies b
on proxy instead
of MarshalledIstance.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 08/02/2017 05:51:07 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invoc
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
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Niclas Hedhman
Sent: 08/02/2017 12:32:35 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
TL;DR
1. It sounds awfully complex, because my gut says that it is n
No, no bootstrap objects.
Cheers,
Peter.
Sent from my Samsung device.
Include 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 str
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
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
TL;DR
1. It sounds awfully complex, because my gut says that it is not a solvable
problem, especially since I don't see 4 distinct cases;
Server(osgi)+Client(osgi), Server(osgi)+Client(plain),
Server(plain)+Client(osgi) and Server(plain)+Client(plain), where the last
one is what we currently have.
lization doesn't succeed, look up another service.
>>
>> Cheers,
>>
>> Peter.
>>
>> Sent from my Samsung device.
>> Include original message
>> Original message
>> From: Peter
>> Sent: 06/02/2017 02:59:09 pm
>> To: dev@river.apa
de 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.)"
Sent: 06/02/2017 03:34:54 pm
To:dev@river.apache.org
Subject: Re: OSGi
Once you rea
message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)"
Sent: 06/02/2017 03:34:54 pm
To:dev@river.apache.org
Subject: Re: OSGi
Once you realize you need some codebase metadata different than mere
list of URLs
the next conclusion is that annotations should be somethi
1 - 100 of 218 matches
Mail list logo
