Hi,
Bharath Kumar wrote:
<snip>
2. We can annotate the proxy object using osgi bundle symbolic name and
version.
3. RMIClassLoader provider can check whether the proxy bundle is
installed or not, If it is not installed, it can install it from configured
repo ( like OBR). We can even use pax-url which adds different URL handlers.
4. Load class/proxy class from correct proxy bundle
If it only was that easy it would have been done a long time ago :)
The question "how to annotate a class" is difficult to answer.
I can see two approaches:
1. Declarative specification of _requirements_ to successfully
deserialize an object (ie. a proxy). The client must have all the
necessary mechanisms in place to resolve, download and install anything
required to satisfy these requirements.
2. Fully specifying what code to download (and ideally - how). This is
the approach of River at this moment. The client simply uses provided
URLs to create an URLClassLoader (of course adding security and
preferred resources but in general that's how it works)
Annotating with bundle id and version is actually half way - it neither
is self contained and sufficient to download code and it does not allow
the client to fully decide how the requirement should be satisfied.
And since the client bundle and the service bundle might be resolved
differently by the container - it may lead to all sorts of pseudorandom
class cast exceptions.
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.
And the main issue with this approach IMHO is that it requires a central
authority that governs the naming and versioning of bundles.
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.
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.
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.
My 2 cents :)
Michal
