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 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.
It is needed to properly annotate a class during serialization.
AFAIK in OSGI you can not find out which fragment (if any) was used to
load a class.
Based on the class loader you can get the bundle, but not the fragment.
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.
My view is different:
1. Without this "serialized object" approach there is no such a thing as
River since there is nothing interesting and novel left.
2. Indeed - the "serialized object" approach is not popular... But my
take on this is that it is because the concept has not been implemented
correctly - both in terms of security and in terms of class loading.
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.
There are no hooks for _class_ resolution - that's what is needed.
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?
With currently implemented PreferredClassProvider it is not possible to
deserialize such an object graph.
Thanks,
Michal
