Hello Kris,
thank you for your profound answer.
I think I'll agree to that when I worked more with Osgi.
Bye,
Andy
Kris Pruden schrieb:
On Dec 2, 2009, at 1:46 PM, Ziegenlippe wrote:
I had some thoughts on that Osgi serialization issue.
If Osgi would disallow to place one and the same class name in
different bundles (even just by convention) it would be always
possible to find the proper bundle for an input data stream.
Unfortunately, OSGi does not impose that restriction. In fact, the
ability for more than one bundle to provide or contain the "same"
class (by FQN) is one of the key benefits of OSGi.
Class name + version (or serialId) would uniquely identify the class
to be loaded. To add the bundle name to the stream does work but is
somehow strange to me.
Fully-qualified class name plus the serial ID might be good enough to
unambiguously identify a class, but I don't think it's guaranteed.
Regardless of the approach, you need to get to a bundle, because
that's how you get the classloader. You could use a heuristic like
this to search for the bundle, but for my application at least, it was
a lot easier to just include the owning bundle name in the serialized
form and use that on the other end. I figure if you can influence the
deserialization logic, you can probably also influence the
serialization logic, so you may as well have them cooperate...
Having the same interface placed in different bundles seem to me
quite mysterious. For the osgi framework interface package you could
use for instance:
the felix bundle: <groupId>org.apache.felix</groupId>
<artifactId>org.osgi.core</artifactId>
<version>1.4.0</version>
or
the osgi bundle:
<groupId>org.osgi</groupId>
<artifactId>org.osgi.core</artifactId>
<version>4.2.0</version>
What for is this good? In my opinion there should be only one
distribution bundle of an interface. This possibly would make also
serialization easier?
One use case I know of for allowing this is to permit multiple
versions of the same bundle to be loaded at the same time, to satisfy
mutually-exclusive version dependencies of other (presumably)
independent bundles.
I agree that this is an odd situation in which to find oneself.
However, when it does happen, and it's not an accident or oversight,
I'd imagine it's because the developers really had no other
alternative. The fact that OSGi can accommodate these scenarios at
all (afaik no other java container has this level of flexibility) is a
bit part of its appeal imo.
Since in Osgi you imports bundles not modules you wouldn't know how
many redistributions of one and the same interface you have in your
environment.
Bye,
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
