Peter,
Please note that Package admin service has been replaced by the Bundle
wiring api. So we may need to use this new api.
Thanks & Regards,
Bharath
On 01-Feb-2017 8:50 AM, "Peter" wrote:
Thanks Nic,
So it follows that the caller has visibility to all imported packages from
other Bundle's C
Another situation that can occur in an object stream, is an outer object,
dependency injects an object during construction. So a Bundle further down the
stack (the stack is built during deserialization, not to be confused with the
call stack) can resovle a class, but the immediate encapsulating
Thanks Nic,
So it follows that the caller has visibility to all imported packages from
other Bundle's ClassLoaders. But not packages from those bundles that haven't
been imported.
Which is the reason I propose switching context with each object in a
serialized graph, to gain the visibility of
Could anyone remove me from this list?
I already unsubscribed but I continue to receive the emails.
Thank you.
On Wed, Feb 1, 2017 at 11:32 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:
> Rant aside...
>
> This is what I am saying all along... Bundles are not good ca
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
As I think you know, the whole purpose of OSGi is to NOT tie the resolution
to Bundles, but to explicitly Exported (with versions) packages. If people
screw up and don't declare the Import/Export package meta data correctly,
then ordinary OSGi may fail just as spectacularly. The difference being
th
Mike, I recall the last time I looked at object based annotations, there was a
backward compatibility issue because both ends of the Marshal streams expect
string based annotations as does RMIClassLoader.
However if you are still keen to investigate object based annotations there's
no reason yo
I think what you mean is, it will work in the majority of cases, but corner
cases could occur that don't, when multiple versions of a (shared class
namespace / api) bundle are installed that could resolve to different versions.
Still I think it's wise to give Bharath the opportunity to attempt t
Unfortunately it is not going to work in the general case as I've shown in
another message.
The issue is that since you do not have influence on how the bundles of
ServiceProxy and ImplementationDetailServiceProxy are resolved, you cannot
guarantee that ImplementationDetail interface is going to b
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 that the full container
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 that the full container is necessary and the client
does not have it - well...
On the other hand. How do you manage upgrades of th
It doesn't sound very intelligent to download an OSGi Container to a
client. It surely is something wrong with that... Proxy should depend on
the deployed services, locally 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ł
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 "
13 matches
Mail list logo
