JGDMS at this time, just the module
structure.At this time, it seems to make sense to also make maven
modules OSGi bundles. However it is important to realise that making
the modules into bundles isn't sufficient in iteself to support OSGi.
This is due to a number of ServiceLoader Provider
Any OSGi people on this list have advice or experience with ensuring
class visibility with Configuration files?
AtomicILFactory accepts a class or ClassLoader argument, for a service,
this is used to locate the ClassLoader of the proxy bundle for
deserialization. A class can be passed
:
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 MarshalledIn
support “multiple
services platform” more readily. It also affords CodeSource level security
controls more readily.
Gregg
> On Oct 2, 2017, at 5:01 AM, Peter <j...@zeus.net.au> wrote:
>
> I'm considering api that may be required for improved OSGi support.
>
> In order fo
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
for ServiceUI
yet, at least not for OSGi.
The reality is that lots of different service implementations might have
common ServiceUI components.
Sounds like this is an opportune time to start thinking more about it.
It also makes me wonder whether MarshalledInstance could accept a URI
codebase string
ositories and follow the approach that published versions are immutable,
then a client would download the code only once, and re-use as necessary.
Or are you thinking of this or something else?
Thanks
Dennis
On Wed, Sep 27, 2017 at 4:59 AM, Peter<j...@zeus.net.au> wrote:
Some updates on
gt; wrote:
> Some updates on thoughts about OSGi:
>
> 1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
> ServiceDiscoveryManager and ProxyPreparer allow provisioning of
> OSGi bundles for Jini services.
> 2. SafeServiceRegistrar lookup results contain only
relying on the
“service” setup to include all of that detail, or is there something we can do,
to wrap ServiceUI into the mechanism you are talking about here?
Gregg
> On Sep 27, 2017, at 3:59 AM, Peter <j...@zeus.net.au> wrote:
>
> Some updates on thoughts about OSGi:
&g
Some updates on thoughts about OSGi:
1. In JGDMS, SafeServiceRegistrar (extends ServiceRegistrar),
ServiceDiscoveryManager and ProxyPreparer allow provisioning of
OSGi bundles for Jini services.
2. SafeServiceRegistrar lookup results contain only instances
d seem best to avoid using codebase annotations in OSGi
unless a developer is very familiar with ClassLoaders etc.
It might be possible to register ClassLoader's with their codebase
annotation locally and associate them with proxy ClassLoaders, via a lookup
list in PreferredClassProvider, al
. There would of course be no
codebase annotation losses, the point is objects may not return to their
originating loader, so it would seem best to avoid using codebase
annotations in OSGi unless a developer is very familiar with
ClassLoaders etc.
It might be possible to register ClassLoader's
The client ClassLoader is determined during delayed unmarshalling and
smart proxy bundle provisioning.
This ensures that deserialization at each endpoint has a compatible
view of classes (as recently discussed on osgi-dev).
It's important at this time to distinguish between remote objects and
remot
ovisioning.
This ensures that deserialization at each endpoint has a compatible
view of classes (as recently discussed on osgi-dev).
It's important at this time to distinguish between remote objects and
remote services, registered with a lookup service.
A remote service must have a pr
Sent from my Samsung device.
Include original message
Original message
From: Peter <j...@zeus.net.au>
Sent: 23/02/2017 03:26:15 pm
To: dev@river.apache.org <dev@river.apache.org>
Subject: OSGi Bundles for services
I've attached some ASCII of the relationship be
that are held here
around security, OSGI, serialization etc.
The questions are very detailed and technical - because there is a lot
of things that are not clear
in the proposed designs.
For example - saying that "deserializing an object is secure because
it is a dynamic proxy" is simply
questions are more
>> important than answers.
>>
>> Regards,
>>
>> Peter.
>>
>> Sent from my Samsung device.
>> Include original message
>> Original message
>> From: Peter<j...@zeus.net.au>
>> Se
07:48:48 pm
To: dev@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 i
message
Original message
From: Peter <j...@zeus.net.au>
Sent: 15/02/2017 07:01:06 pm
To: dev@river.apache.org <dev@river.apache.org>
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Oh I thought it was part of your SmartProxyWrapper?
original message
Original message
From: Michał Kłeczek <mic...@kleczek.org>
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 answered any of them.
. Sometimes the right questions are more important
than answers.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter<j...@zeus.net.au>
Sent: 15/02/2017 12:58:55 pm
To: dev@river.apache.org<dev@river.apache.org>
Subject: Re: OSGi
/ assumptions. Sometimes the right questions are more important
than answers.
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter <j...@zeus.net.au>
Sent: 15/02/2017 12:58:55 pm
To: dev@river.apache.org <dev@river.apache.org>
Subje
,
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 Complete Was: OSGi - deserialization remote invocation
strategy
So I've given i
- 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 discovery providers with authentic
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.
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
.
Sent from my Samsung device.
Include original message
Original message
From: Peter <j...@zeus.net.au>
Sent: 14/02/2017 09:34:01 pm
To: dev@river.apache.org <dev@river.apache.org>
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
T
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
Samsung device.
Include original message
Original message
From: Michał Kłeczek <mic...@kleczek.org>
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:
> Som
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
mic...@kleczek.org>
Sent: 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
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
. 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 <mic...@kleczek.org>
Sent: 14/02/2017 01:45:43 am
To: dev@river.apache.org
Subject: Re: OSGi NP Co
Classloader from being gc'd.
Option 2 is loosely coupled ie the OSGi way and published via the service
registry, so multiple client consumer bundles may utilise it without causing a
ClassLoader reference to any client consumer bundle.
For a smart proxy listener, the service could allow a smart proxy
01:55:56 am
To: dev@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
ung device.
Include original message
Original message
From: Michał Kłeczek <mic...@kleczek.org>
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
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
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
This has the issue that you are not reusing any OSGi container class
loading infrastructure
2. Use OSGi container to install proxy's class bundle - which has other
problems discusses so far
IMHO there is a third way - but I am still not finished with it :)
Thanks,
Michal
Peter wrote:
My take
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 <mic...@kleczek.org>
Sent: 14/02/2017 01:27:09 am
To: dev@river.apache.org
Subject: Re: O
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: OSGi - deserialization remote invocation
strategy
So if the CodeDownloadingSmartProxyWrapper implements AtomicSerial then
it is fine?
Cool
we can do 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
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
: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 validation fist as well,
can't it?
BTW - how does the client unmarshalls SafeServiceRegistrar proxy in a
secure way?
Thanks,
,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek <mic...@kleczek.org>
Sent: 14/02/2017 01:13:04 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
S
There are actually two things that we are discussing at the same time:
1. The need to have an "installer" object and how it should be provided
to the client
2. The algorithm of class loader resolution in OSGi
These two things are orthogonal to each other and your question is abou
solve this problem?
Regards,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek <mic...@kleczek.org>
Sent: 14/02/2017 12:39:40 am
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invo
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
But what if the client has MULTIPLE clients - each with its own exact
API version?
OSGi handles this case just fine with service trackers.
Do you want to give up on this?
Thanks,
Michal
Peter wrote:
You can however for each service api package version, it's all in the smart
proxy bundle
Original message
From: Peter <j...@zeus.net.au>
Sent: 14/02/2017 12:33:54 am
To: dev@river.apache.org <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
he.org
Subject: 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 Rive
,
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.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation
strategy
Peter
one service per each
service interface version any client might require.
No... You have to be able to make this class resolution decision on the
client.
And if the client VM allows to have many class loading context at the
same time (as is the case with OSGI) then
the infrastructure has
.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
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
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
Samsung device.
Include original message
Original message
From: "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Sent: 14/02/2017 12:00:02 am
To: dev@river.apache.org
Subject: 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
I changed it to highlite Nic's point that it's not feasible to resolve and
provision osgi bundle transitive dependencies during deserialization because
the time taken to do that can be excessive due to NP Complete nature of
resolution.
It is incompatible with stream codebase annotations.
I
>
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 an
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
o. o.)" <michal.klec...@xpro.biz>
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 cla
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>
Sent: 13/02/2017 11:34:45 pm
To: dev@river.apache.org
Subj
t;j...@zeus.net.au>
Sent: 13/02/2017 11:15:27 pm
To: dev@river.apache.org <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,
ioning and resolving a bundle,
deserializing the smart proxy and registering it with the OSGi service
registrar in a readResolve or readObject method?
How do you propose the connection from the client to the service established in
order to enable this to occur?
How do you prevent an attacker from
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
proble
So this object that you have with a locally installed class is tasked with
authenticating the remote service, provisioning and resolving a bundle,
deserializing the smart proxy and registering it with the OSGi service
registrar in a readResolve or readObject method?
How do you propose
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
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 bundle chosen by the container
the smart proxy first?
More comments inline below.
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
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
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
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
ryManager is the solution.
ServiceDiscoveryManager performs discovery and looks up services from
registrars based on filters. ServiceDiscoveryManager then performs
local filtering. This allows time for proxy bundles to be installed,
resolve, started and confirmed type compatible, prior to th
,
Peter.
Sent from my Samsung device.
Include original message
Original message
From: Peter <j...@zeus.net.au>
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,
See inline
developers to assist.
The proxy implementation (provider) is abstracted behind the service api
completely, typical of OSGi practise, ServiceDiscoveryManager allows
time for service proxy's to be wired up, prior to deserialization using
delayed unmarshalling.
The consumer must use the service api to
eryManager then performs
local filtering. This allows time for proxy bundles to be installed,
resolve, started and confirmed type compatible, prior to them being
made available (via OSGi service registry if you so desire) for client
use.
The new interfaces that are part of JGDMS tha
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
> On Feb 7, 2017, at 8:56 AM, Michał Kłeczek (XPro Sp. z o. o.)
> <michal.klec...@xpro.biz> 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
Maybe there are some misunderstanding somewhere... see below;
On Wed, Feb 8, 2017 at 3:35 AM, Peter <j...@zeus.net.au> 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.
>
Correct in the second instance.
Sent from my Samsung device.
Include original message
Original message
From: Michał Kłeczek <mic...@kleczek.org>
Sent: 08/02/2017 09:24:21 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote invocation strategy
So in thi
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
Kłeczek <mic...@kleczek.org>
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 RemoteEventLis
Clarification inline.
Sent from my Samsung device.
Include original message
Original message
From: Peter <j...@zeus.net.au>
Sent: 08/02/2017 05:35:57 am
To: dev@river.apache.org <dev@river.apache.org>
Subject: 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
of MarshalledIstance.
Cheers,
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: 08/02/2017 05:51:07 am
To: dev@river.apache.org
Subject: Re: OSGi - deserialization remote inv
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
Hi Nic,
I'm currently only considering OSGi server -> OSGi client. Mick's
investigating all four options.
Not expecting the client calling bundle to resolve everything, hence the stack,
so we have the full visibility of the bundle of the class that was last
resolved, so we can resolve
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.)" <michal.klec...@xpro.biz>
Sent: 08/02/2017 12:28:50 am
To: dev@river.apache.org
Subject: Re: OSGi - deseri
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
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 loadin
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
Proposed JERI OSGi class loading strategy during deserialization.
Record caller context - this is the default bundle at the beginning of
the stack. It is obtained by the InvocationHandler on the
client side. The InvocationDispatcher on the server side has the
calling context of the Remote
chal.klec...@xpro.biz> wrote:
>
> 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 n
wrote:
For the sake of simplicity it's probably best if OSGi and non interact only using reflection proxy's and have their own djinn groups so code downloading is unnecessary between them.
At least that's how I'd consider introducing it into an existing djinn.
A jvm that doesn't have version
the assumption that codebase
annotations are Strings - it has all the necessary extension points
available.
I've already started writing the test suite for the thing and hope to
present it soon.
Thanks,
Michal
Peter wrote:
For the sake of simplicity it's probably best if OSGi and non interact
For the sake of simplicity it's probably best if OSGi and non interact only
using reflection proxy's and have their own djinn groups so code downloading is
unnecessary between them.
At least that's how I'd consider introducing it into an existing djinn.
A jvm that doesn't have version
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 t
annotation (the smart
proxy). This is similar in some ways to never preferred, where locally visible
classes will be selected first.
The strategy is to let OSGi do all the dependency wiring from bundle manifests.
Classes not visible will be visible from a common package import class, except
for poorly
Thanks Nic,
If annot
You've identified the reason we need an OSGi specific RMIClassLoaderSpi
implementation; so we can capture and provide Bundle specific annotation
information.
Rmiclassloaderspi's loadClass method expects a ClassLoader to be passed in, the
context ClassLoader is used
1 - 100 of 207 matches
Mail list logo
