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 container do the resolution
- it is designed to do it efficiently).
> Of course then we have a problem with classes that are not from any
exported package but from internal bundle class path - then bundle id and
version might be necessary.
> Then of course there is a question of classes from fragment bundles -
this is totally unsolvable since AFAIK there is no way to get the fragment
information based on the class loader of a class.
Not that I grasp why it is needed, but you can get the Bundle information
from the classloader, IF the class was loaded by OSGi. OSGi defines
BundleClassLoader, so you simply cast the classloader to that, and with
that you can get the Bundle and the BundleContext, which together should be
able to give you all the meta info that you could need.
> And the main issue with this approach IMHO is that it requires a central
authority that governs the naming and versioning of bundles.
It is rather rare that Bundle management is needed. The OBR (OSGi Bundle
Repository) spec could be leveraged to resolve "package name+version" to
bundle location, and deploying an OBR capable service on a network is
relatively simple (serve a XML over HTTP).
> Approach 2 in OSGI would require annotating a class not with a bundle but
with a piece of information that would allow
> the client to download the _BundleWiring_ of the proxy - it unambiguously
specifies the class loader graph that is
> required to be recreated by the client to deserialize an object..
>
> When I tried to implement it - it appeared to me that the main issue is
that it simply makes the whole OSGI with its declarative
> dependency resolution moot - we need to totally bypass it to transfer
objects between containers anyway. So the only thing
> we actually would use from an OSGI container is its capability of
non-hierarchical class loading.
The concept of "download the proxy, both code and state" was quite novel in
1999 when I first heard of Jini. But I think it should be recognized that
it both introduces a lot of security problems as well as not being the only
way this can be done. For instance, the proxy could be an HTML page, which
downloads JavaScript which binds into a sandbox provided. I think that the
"serialized object" should not be a requirement eventually, and with that
removed, the OSGi environment can help quite considerably aiding the
dynamic nature of River.
> One step towards solving the above issues is to implement the idea of
code base annotations being objects
> implementing a well known interface - that would at least allow us to
abstract away from the exact format of
> the annotation data. But I do not have a clear idea on how to solve other
OSGI integration issues.
As Peter observed, Pax URL allows a whole bunch of URL schemes, which you
could be annotated in the serialized objects, just like URL codebases are
today. For instance, Maven "coordinates" could be in the annotations and
OSGi loads bundles on-demand. Paremus also implemented a "bundle garbage
collector" in some manner, which unloaded unused bundles eventually.
Furthermore, there are defined hooks in OSGi for the resolution of service
registration and service lookup, which I think River should exploit. There
seems to be a huge complementary intersection right there.
> 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 RemoteEventListener, Serializable {
> private final JavaSpace space;
> public void notify(RemoteEvent evt) {
> space.write(createEntry(evt), ...);
> }
> }
>
> It is NOT possible to do currently. It requires non-hierarchical class
loading. It is not easy to solve. It would open a whole lot of
possibilities.
I am probably too ignorant to see it; What exactly is "NOT possible" with
the above use-case snippet?
Cheers
--
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java
